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I.  INTRODUCTION 


Since  its  inception  in  1978,  the  Army  Unit  Resiliency  Analysis  (AURA) 
methodology  has  been  applied  to  an  ever  broader  spectrum  of  unit-level 
survivability /sustainability  problems  by  an  increasing  number  of  ’nalysts  in  the 
United  States  and  abroad.  Meanwhile,  tne  methodology  has  continued  to  grow  to 
respond  to  special  needs  that  have  arisen  in  the  many  applications.  This  situation 
resulted  in  a  strong  need  for  the  publication  of  an  AURA  user’s  manual  to  update 
the  AURA  user  community  on  the  ^urrent  incut  command  formats.  The  first 
such  a  manual  was  published  in  1985*  and  updated  in  1988/ 

Since  the  publication  of  these  manuals,  several  new  methodologies  and  asso¬ 
ciated  inputs  have  been  added,  including  a  major  extension  to  the  sleep  depriva¬ 
tion  model,  a  new  methodology  for  degradation  due  to  heat  stress,  and  a  new 
methodology  for  dose  accumulation.  Thus,  the  need  for  an  updated  manual  has 
become  apparent.  This  report  is  designed  to  fill  th.-t  need. 

As  with  the  previous  user’s  manuals,  the  purpose  of  this  report  is  quite  lim¬ 
ited,  viz.,  to  provide  a  concise  compendium  of  input  commands  and  formats  for 
the  AURA  computer  simulatior  model.  It  is  assumed  that  the  reader  is  reason¬ 
ably  familiar  with  the  AURA  family  of  methodologies  in  general,  and  with  the 
purpose  and  function  of  the  many  options  of  the  AURA  code  itself.  Therefore, 
only  a  brief  description  of  command  functions  will  be  given  with  each  entry.  For 
a  detailed  description  of  the  AURA  methodology,  the  user  is  referred  to  Volume  1 
of  the  AURA  Programmer/Ana'yst  Guide/ 

The  command  descriptions  in  this  report  are  grouped  by  function:  those 
that  describe  assets  are  presented  together,  followed  by  those  that  describe  threat 
weapons,  etc.  Within  each  grouping,  the  entries  are  arranged  alphabetically. 


1.  J.  Terrence  Klopcic,  Input  Manual  for  the  Army  Unit  Resiliency  Analysis  (AURA)  Metho¬ 
dology,  USA  Ballistic  Research  Laboratory,  BRL-TR-2670,  (SEP  85),  AD  A159327, 
(UNCLASSIFIED). 

2.  J.  Terrence  Klopcic,  Input  Manual  for  the  Army  Unit  Resiliency  Analysis  (AURA)  Metho¬ 
dology:  1988  Update,  USA  Ballistic  Research  Laboratory,  BRL-TR-2914,  (MAY  88), 
(UNCLASSIFIED). 

3.  R.  Sheroke,  et  al,  Programmer/Analyst  Guide  for  the  Army  Unit  Resiliency  Analysis 
(.AURA)  Computer  Simulation  Model,  Volume  1:  AURA  Methodology,  USA  Ballistic 
Research  Laboratory,  DRAFT  REPORT,  (AUG  90),  (UNCLASSIFIED). 
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Appendix  A  is  provided  to  illustrate  and  clarify  the  organization  and  format 
of  AURA  input  runstreams.  Contained  within  the  appendix  are  examples  of 
input  runstreams  representing  the  hypothetical  mission  of  an  Ammunition  Supply 
Point  (ASP)  unit  in  a  nuclear,  conventional,  and  chemical  scenario.  Appendix  O 
provides  a  complete  index  of  all  AURA  commands. 
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II.  EXECUTION  and  GENERAL  INFORMATION 


A.  EXECUTION 

Described  below  is  a  brief  overview  of  the  inputs  and  files  required  to  exe¬ 
cute  the  AURA  model.  The  user  is  referred  to  Volume  2  of  the  AURA 
Programmer/Analyst  Guide4  for  a  detailed  description  of  the  execution  process. 

1.  Required  Files.  Execution  of  the  AURA  model  requires  the  following  data 
and  files: 

Standard  input  data; 

AURA  input  runstream  file; 

AURA  lethality  file(s); 

Executable  AURA  binary  code. 

The  format  and  contents  of  each  of  these  files  will  be  described  in 
the  following  sections. 

2.  Standard  Input.  It  is  necessary  to  assemble  the  data  and  filename(s)  for  an 
AURA  run  to  be  read  as  standard  input.  The  standard  input  data  must  be  in  the 
following  format: 

Comment  line  describing  AURA  run 

Offset  Coordinates  (used  to  reposition  unit  -  optional) 

TP2  /  TP3  /  TP4  (whichever  is  needed,  if  any) 

TP5 

Output  filename 

4  character  unique  run  identifier  (optional) 
where: 

TP2  is  the  name  of  the  conventional  lethality  file; 

TP3  is  the  name  of  the  nuclear  lethality  file; 

TP4  is  the  name  of  the  chemical  lethality  file; 

TP5  is  the  name  of  the  AURA  input  runstream. 

Note: 

It  is  generrlly  convenient  to  assemble  the  standard  input  data  and  file¬ 
names  into  a  file  to  be  read  as  standard  input.  The  ‘xqtaura’  shell  pro- 


4.  R.  Sheroke,  et  al,  Programmer /Analyst  Guide  for  the  Army  Unit  Resiliency  Analysis 
(AURA)  Computer  Simulation  Model,  Volume  2:  AURA  Source  Code,  USA  Ballistic 
Research  Laboratory,  BRL-TR-3103,  (JUL  90),  (UNCLASSIFIED). 
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gram  creates  such  a  file  (called  FILES)  which  is  read  into  AURA  as  stan¬ 
dard  input. 

3.  AURA  Input  Runstream  File.  The  AURA  input  runstream  file  contains 
the  commands  and  formats  needed  to  establish  the  AURA  modeling  scenario. 
The  organization,  conventions,  commands  and  functions  of  the  AURA  input  run¬ 
stream  are  the  subject  of  this  report. 

4.  AURA  Lethality  File(s).  An  AURA  lethality  file  contains  the  weapon 
effects  data  for  the  corresponding  desired  modeling  scenario.  AURA  uses  the  fol¬ 
lowing  standard  weapon  effects  methodologies  for  each  lethality  scenario: 

Conventional  Lethality  -  JTCG/ME  FULL  SPRAY  methodology;^ 

Nuclear  Vulnerability  -  NUDACC  methodology. 

Chemical  Dispersion  -  NUSSE  methodology. 

Detailed  descriptions  of  the  above  methodologies  are  beyond  the  scope  of  this 
report.  The  interested  reader  is  referred  to  the  references  cited  below.  For¬ 
mat  examples  of  the  conventional,  nuclear,  and  chemical  lethality  files  are 
illustrated  in  Appendix  B  of  Volume  2  of  the  AURA  Programmer/ Analyst 
Guide.8 

5.  Executable  AURA  Binary  Code.  The  executable  AURA  binary  code  is 
derived  from  the  successful  FORTRAN  compilation  of  the  file  ’AURA.f’  (see  Sec¬ 
tion  III  of  Volume  2  of  the  AURA  Programmer/Analyst  Guide9). 


5.  Computer  Program  for  General  Full  Spray  Material  MAE  Computations,  Joint  Technical 
Coordinating  Group  for  Munitions  Effectiveness,  61  JTCG/ME-79-1-1,  (JAN  79), 
(UNCLASSIFIED). 

6.  William  L.  Vault,  Vulnerability  Data  Array:  The  Agreed  Data  Base  -  Final  Report,  Harry 
Diamond  Laboratories,  HDL-TR-1906,  (JUL  80),  (SECRET). 

7.  R.  Saucier,  NUSSES  Model  Description,  U.S.  Army  Chemical  Research,  Development  and 
Engineering  Center,  CRDEC-TR-80746,  (MAY  87),  (UNCLASSIFIED). 

8.  R.  Sheroke,  et  al,  Programmer/Analyst  Guide  for  the  Army  Unit  Resiliency  Analysis 
(AURA)  Computer  Simulation  Model,  Volume.  ?.•  AURA  Source  Code.  USA  Ballistic 
Research  Laboratory,  BRL-TR-3103,  (JUL  90),  (UNCLASSIFIED). 

9.  Ibid. 
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B.  GENERAL  INFORMATION 


1.  Formats.  All  AURA  data  sets  are  preceded  by  a  mnemonic  control  card  and 
followed  by  an  END  card.  For  example,  the  mnemonic  control  to  input  deploy¬ 
ment  data  is  "DEPLOYMENT".  Depending  on  the  particular  mnemonic,  several 
cards  of  data  may  then  follow:  the  most  recent  mnemonic  "remains  in  effect" 
until  followed  by  an  END  card  or  superseded  by  another  mnemonic  card.  Thus, 
if  several  pieces  of  data  are  appropriate  for  a  particular  mnemonic  (e.g.  several 
items  are  to  be  deployed),  the  DEPLOYMENT  mnemonic  need  only  appear  once, 
followed  by  several  cards  of  deployment  data.  Each  data  set  should  end  with  an 
END  card.  However,  if  an  END  card  is  missing,  the  input  routine  will  detect  the 
following  mnemonic  control  card  and  begin  a  new  data  set.  Mnemonic  control 
cards  may  be  abbreviated  to  the  first  six  letters. 

2.  Order.  With  few  exceptions,  the  various  data  sets  may  be  input  in  any  order. 
The  major  exceptions  to  the  any-order  rule  are: 

1.  The  first  data  set  must  be  the  NAMES  or  REPERTOIRE  data  set. 

2.  Functional  forms  (LINKs,  CREWs,  SUBCHAlNs,  ORLINKs,  COMPOUND 
LINKs)  must  be  input  before  any  higher  level  functional  forms  (CREWs, 
SUBCHAlNs,  ORLINKs,  COMPOUND  LINKs,  CHAINs)  which  use  them. 

3.  Number  Types.  Numbers  in  AURA  are  either  INTEGERS  or  REALS. 
(REALS  are  floating  point  numbers  or  exponential  numbers  with  decimal  points.) 
AURA  checks  to  assure  that  the  anticipated  combination  of  INTEGERS  and 
REALS  is  input  and  will  terminate  a  run  on  a  FATAL  FORMAT  ERROR  if  an 
errant  combination  is  detected.  Unless  indicated  otherwise,  the  values  of  all  non¬ 
character  AURA  input  parameters  is  0  if  integer  of  0.0  if  real.  The  following  sec¬ 
tions  specify  the  types  of  numbers  anticipated. 

4.  Names,  General.  Names  for  assets,  weapons  and  functional  structure  parts 
(LINKs,  CREWs,  SUBCHAlNs,  ORLINKs,  COMPOUND  LINKs)  may  not  contain 
more  than  18  characters,  including  embedded  blanks.  Use  of  special  characters 
within  names  (see  following  section)  may  cause  fatal  errors  or  unanticipated 
behavior  and  should  be  avoided. 

5.  Special  Characters. 

(a)  Continuation  Cards.  Data  may  be  continued  on  a  subsequent  card. 
A  continuation  card  is  denoted  by  a  dollar  sign  ($)  as  the  first  character  on  the 
card,  followed  by  data  in  the  appropriate  format.  A  comma  may,  but  need  not, 
follow  the  dollar  sign. 
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Continued  data  falls  into  two  types:  supplementary  data  (data  that  is 
different  from  that  of  the  preceding  card)  and  overflow  data  (of  the  same  type 
which  did  not  fit  on  the  preceding  card).  Several  data  sets  allow  options  which 
must  be  entered  on  supplementary  continuation  cards.  For  example,  to  specify 
L:i  alternate  posture  for  a  deployed  asset,  the  deployment  data  card  is  followed  by 
a  supplementary  continuation  card  containing  the  alternate  posture  code  and  the 
mean  time  to  change  posture. 

(b)  Comments.  The  pound  sign  (#)  immediately  stops  the  scan  of  a  card 
by  the  AURA  read  routines.  Thus  the  user  can  insert  comment  cards  (for  his  own 
use,  not  to  be  read  as  data)  into  an  AURA  runstream  by  beginning  the  card  with 
a  pound  sign.  Similarly,  any  data  card  can  have  a  comment  appended,  as  shown 
below. 


#THIS  IS  AN  EXAMPLE  OF  COMMENTS  IN  A  RUNSTREAM 
DEPLOYMENT  #  BASED  ON  FM  -  XYZ 
MECHANIC,  100.,  352.,  1.0,  1,1, 1,1, 1,0  #  MOTOR  POOL 

(c)  Functional  Structure  Names.  As  described  in  the  following  sec¬ 
tions,  names  for  the  CREW,  SUBCHAIN,  ORLINK  and  CPLINK  functional 
structure  begin  with  =,  *,  +  and  !  respectively. 

(d)  Embedded  Procedure  Commands.  Potential  extensions  of  the 
AURA  input  routines  include  the  development  of  embedded  procedures,  which 
will  be  signified  by  a  backslash  (\)  in  column  1.  An  example  of  such  a  procedure 
is  the  embedded  offset  (under  DEPLOYMENT)  which  translates  the  unit  to  new 
deployment  coordinates. 
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6.  AURA  Terminology. 


ASSETS  -  Personnel  and  equipment  belonging  to  and  deployed  with  the  unit. 

BASELINE  -  Initial  set  of  input  data  from  which  all  related  AURA  excursions 
for  a  specific  study  will  be  generated. 

CASUALTY  -  Personnel  asset  removed  from  this  simulation.  This  is  a  function 
of  the  kill  criteria  selected  by  the  user. 

CHAIN  -  A  collection  of  AURA  constructs  which  span  the  activities  of  a  unit  to 
represent  the  unit  mission.  A  chain  is  the  highest  level  AURA  construct. 

CONSTRUCT  -  A  task  or  combination  of  tasks.  Each  construct  indicates  a 
specific  relationship  between  its  elements  (i.e.  an  ORLINK  represents  an  ’OR’ 
relationship,  SUBCHAIN  represents  an  ’AND’  relationship,  etc.). 

COMPOUND  LINK  -  An  AURA  construct  used  to  represent  several  groups  of 
tasks/jobs  such  that  the  total  activity  is  a  summation  of  the  independent  contri¬ 
butions  of  the  different  constructs.  A  compound  link  may  be  comprised  of 
orlinks,  subchains,  crews,  and/or  links. 

CREW  -  An  AURA  construct  used  to  represent  sets  of  subtasks  that  must  work 
together  to  accomplish  part  of  the  mission.  The  relationship  between  these  sub¬ 
tasks  are  generalized  parallel  structures  and  all  crew  tasks  are  links. 

DUMMYLINK  -  A  job  which  has  no  asset  of  the  same  name.  Dummylinks  are 
links  which  have  no  particular  assets  assigned  to  them  but  are  filled,  when 
needed,  by  substitutes. 

EXCURSION  -  Input  set  for  which  initial  baseline  input  data  have  been  varied 
from  the  baseline  to  determine  the  sensitivity  of  the  results  to  the  input  parame¬ 
ters. 

FUNCTIONAL  STRUCTURE  -  The  organization  of  activities  and  tasks  that 
result  in  the  accomplishment  of  a  unit’s  mission.  These  activities  are  represented 
by  the  organization  of  AURA  constructs.  A  detailed  description  of  the  organiza¬ 
tion  and  content  of  the  AURA  functional  structures  is  included  in  Volume  1  of 
the  AURA  Programmer/Analyst  Guide.1 


10.  R.  Sheroke,  et  al,  Programmer /Analyst  Guide  for  the  Army  Unit  Resiliency  Analysis 
(AURA)  Computer  Simulation  Model,  Volume  1:  AURA  Methodology,  USA  Ballistic 
Research  Laboratory,  DRAFT  REPORT,  (AUG  90),  (UNCLASSIFIED). 
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HOMELINK  -  A  link  which  has  the  same  name  as  the  asset  that  fills  it.  An 
asset  is  immediately  available  for  its  ’homelink’  task  and  contributes  to  the 
homelink’s  accomplishment  at  100  percent  effectiveness  unless  degraded  other¬ 
wise. 


LETHALITY  -  The  ability  of  a  weapon  to  inflict  damage. 


LETHALITY  FILE  -  The  input  file  containing  the  lethality  data  for  the 
environment(s)  being  modeled. 


Environment  Lethality  file 


Conventional 

Nuclear 

Toxic/Chemical 


FORTRAN  unit  #  2 
FORTRAN  unit  #  3 
FORTRAN  unit  #  4 


LETHALITY  EVENT  -  A  process  by  which  the  AURA  model  simulates  the 
effects  (damage,  contamination,  dosage,  etc.)  resulting  from  a  conventional,  chem¬ 
ical,  or  nuclear  attack. 


LINK  -  The  lowest  task/job  delineation  of  all  AURA  constructs.  Links  may  be 
used  as  independent  constructs  or  combined  to  represent  any  higher  AURA  con¬ 
struct. 


MISSION  -  Performance  rate  or  capability  upon  which  the  study  unit  is  being 
evaluated.  For  example,  a  supply  unit  might  be  evaluated  on  its  ability  to  issue 
2000  tons  of  supplies  per  day. 

OPTIMIZATION  -  The  process  by  which  the  AURA  model  allocates  available 
assets  in  the  attempt  to  maximize  the  effectiveness  of  the  unit.  The  optimization 
process  is  performed  over  all  mission  constructs  which  can  be  improved  during 
the  course  of  the  mission. 

ORLINK  -  An  AURA  construct  representing  mutually  exclusive  choices  for  the 
accomplishment  of  part  of  the  mission.  Orlinks  may  be  comprised  of  subchains, 
crews,  and/or  links. 

RECONSTITUTION  -  A  ’snapshot’  of  the  unit’s  status  taken  at  specified  time 
periods  within  an  AURA  execution. 

RECONSTITUTION  EVENT  -  A  process  by  which  the  AURA  Asset  Alloca¬ 
tion  Algorithm  (the  commander’s  decision  model)  simulates  the  reallocation  of 
surviving  assets  in  order  to  optimize  the  unit’s  mission  accomplishment. 
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REPLICATION  -  One  complete  pass  through  the  events  of  an  AURA  simula¬ 
tion.  Due  to  variances  resulting  from  random  number  generation,  several  (50  or 
more)  replications  are  generally  specified  and  the  unit  effectiveness  and  casualty 
estimates  are  averaged  over  all  replications.  This  process  insures  a  more  statisti¬ 
cally  sound  representation  of  the  events  simulated. 

RUNSTREAM  -  The  input  file  (FORTRAN  unit  #  5)  containing  the  AURA 
commands  and  parameters  required  to  model  a  particular  scenario. 

SEGMENT  -  An  element  in  a  chain.  A  segment  can  be  a  compound  link,  orlink, 
subchain,  crew,  or  a  link. 

SLUNIT  -  (SLeep  unit).  Unit  of  measure  used  to  represent  the  amount  of  rest 
associated  with  a  personnel  asset.  1  SLUNIT  =  1  minute  of  fully  efficient  rest. 

SUBCHAIN  -  An  AURA  construct  used  to  represent  a  group  of  tasks  which 
must  work  together  to  accomplish  part  of  the  mission.  A  subchain  may  be 
comprised  of  crews  and/or  links. 

SURVIVOR  -  An  asset  that  is  still  available  to  the  unit  after  an  attack. 

UNIT  EFFECTIVENESS  -  The  capability  of  the  unit  to  perform  its  selected 
mission.  Note:  The  unit’s  effectiveness  is  evaluated  based  upon  its  ability  to  per¬ 
form  selected  mission(s)  which  have  an  associated  rate  defined  as  100%  perfor¬ 
mance. 

VULNERABILITY  -  Susceptibility  of  a  target  to  damage. 

WEAK  LINK  -  The  individual  tasks  in  a  construct  which  have  the  most  degrad¬ 
ing  effects  on  the  capability  of  the  construct.  There  may  be  more  than  one 
WEAK  LINK. 

WEAPON  -  Incoming  weapon.  The  term  ’weapon’  includes  warheads  and 
delivery  systems. 


9 


7.  Units,  Times  and  Time  Intervals.  Much  of  the  data  which  is  input  into 
AURA  has  associated  units,  most  commonly  length  or  time.  It  is  essential,  there¬ 
fore,  to  establish  a  consistent  system  of  units,  since  parameter  values  can  be 
markedly  different  in  different  systems.  (For  example,  an  event  time  could  be 
input  as  3600.,  60.,  or  1.  depending  on  whether  seconds,  minutes  or  hours  are 
being  used.) 

With  the  exception  of  certain  nuclear  algorithms  which  contain  built-in 
basic  data,  AURA  can  be  used  with  any  consistent  set  of  units.  However,  achiev¬ 
ing  such  consistency  may  require  a  g-eat  deal  of  thoroughness.  For  example,  both 
length  and  time  are  buried  in  the  threshold  value  for  chemical  alarm  functioning. 
Therefore  the  following  set  of  units,  consistent  with  the  nuclear  algorithms,  are 
recommended: 


MEASURES  UNITS 


Time 

Distance 

Angles 

Toxic  deposition 
Toxic  dose 
Nuclear  dose 
Nuclear  yield 


minutes 

meters 

degrees 

mi  digrams/  meter  2 

milligrams-min/meter^ 

rads  (cGy) 
kilotons  (kt) 


Some  of  the  AURA  options  require  the  input  of  a  time  duration.  For  exam¬ 
ple,  to  allow  individuals  under  attack  to  change  posture  requires  specifying  the 
mean  time  for  the  change.  On  the  other  hand,  those  options  which  result  in  the 
scheduling  of  an  event,  such  as  the  options  which  specify  that  an  attack  will 
occur,  require  input  of  an  absolute  (cluck)  time  into  the  simulation.  In  this 
report,  all  time  inputs  will  be  identified  as  (intrvl)  or  (clock)  to  indicate  whether 
the  value  is  a  duration  interval  or  an  absolute  event  time. 


8.  AURA’s  Coordinate  Systems.  Three  coordinate  systems  are  used  in 
AURA  to  express  data  that  refer  to  geographical  locations  or  extents.  These  coor¬ 
dinate  systems  are  defined  as  follows: 

(a)  The  Unit  Coordinate  System.  Any  right-handed  coordinate  system 
may  be  used  to  lay  out  the  study  unit.  Any  particular  point  in  the  unit,  such  as 
the  geographical  center  or  "lower  left"  corner,  may  be  designated  as  the  origin  of 
the  unit  coordinate  system,  and  all  other  unit  elements  are  deployed  relative  to 
that  point.  Note:  All  target  and  deployment  points  from  the  fire  direction  and 
wind  direction  coordinate  systems  are  defined  relative  to  points  within  the  unit 
coordinate  system. 
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(b)  The  Incoming  Fire  (Range-Deflection)  System.  Threat  weapon 
parameters  are  specified  in  range  and  deflection,  where  range  is  in  the  direction  of 
the  incoming  fire,  and  deflection  is  perpendicular  to  range  such  that  range- 
deflection  define  a  right-handed,  horizontal  coordinate  system.  The  user  can 
specify  the  orientation  of  the  range  direction  relative  to  the  unit  coordinate  sys¬ 
tem. 


(c)  The  Wind  Direction  (Downwind-Crosswind)  System.  Chemical 
cloud  dispersion  is  specified  in  the  downwind  and  crosswind  directions,  which  are 
defined  to  form  a  right-handed,  horizontal  coordinate  system.  The  user  can 
specify  the  orientation  of  the  downwind  direction  relative  to  the  unit  coordinate 
system. 

Usage  of  the  AURA  coordinate  systems  is  summarized  in  Table  1,  while  Fig¬ 
ure  I  illustrates  the  AURA  coordinate  systems. 


Tabic  1.  Coordinate  Systems  for  Geographically  Related  Parameters 


Parameter 

Coordinate  System 

Comment 

Deployment  of  items 

UNIT 

Define  X-Y  System 

Aim  point 

UNIT 

e.g.  signature  point 

Target  Location  Error 

RANGE-DEFLECTION 

Measured  from  aim  point 

Dr'ivery  errors 

RANGE-DEFLECnON 

Measured  from  aim  point 

Burst  point  of  munitions 

UNIT 

Internally  computed  by  AURA 

Conventional  weapon 
effects  (Lethal  radii) 

RANGE-DEFLECTION 

Measured  from  burst  point 

Chemical  contamination 
and  vapor  clouds 

DOWNWIND-CROSS  WIND 

Measured  from  burst  point 

Volley  parameters 
(length,  volley,  etc.) 

RANGE-DEFLECTION 

Measured  from  aim  point 
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Unit  Coordinate  System 


The  incoming  fire  and  wind  direction  coordinate  systems  are  defined  relative 
to  the  unit  coordinate  system.  AURA  ultimately  converts  any  coordinates  specified 
in  incoming  fire  (or  wind  direction)  coordinates  to  unit  system  coordinates. 


Figure  1.  AURA's  Coordinate  Systems 
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III.  NAMES 


The  first  data  set  in  an  AURA  input  stream  is  a  list  of  names  to  be  used  for 
assets  and  weapons.  This  block  may  be  headed  by  a  NAMES  or  REPERTOIRE 
card  and  must  be  terminated  (after  ail  asset  and  weapon  names  have  been  listed) 
by  one  END  card.  A  group  of  asset  names  must  be  headed  by  an  ASSETS  card; 
weapon  names  must  be  headed  by  a  WEAPONS  card.  Note:  An  END  card  may 
not  be  placed  between  the  asset  and  weapon  name  lists. 

Format: 

ASSETS 

asset  namel,  alternate  namela,  alternate  namelb,  .... 

asset  name2,  alternate  name2a,  .... 

WEAPONS 

weapon  namel,  alternate  nameli,  alternate  namelj, .... 

weapon  name2,  alternate  name2i,  .... 


where: 

all  names  conform  to  restrictions  listed  on  p.  5 


Each  asset  and  weapon  must  have  at  least  one  unique  name.  Alternate 
names  are  used  to  associate  common  parameters  to  groups  of  assets  or  weapons. 
To  invoke  certain  code  defaults,  the  following  alternate  names  MUST  be  used: 


CONVENTIONAL  - 

NUCLEAR 

PERSONNEL 

TOXIC 


must  be  attached  to  each  conventional  or  combined  conven¬ 
tional/toxic  weapon  attack 

must  be  attached  to  each  nuclear  weapon  (NUKE  can  be 
used  as  a  substitute) 

must  be  attached  to  each  personnel  asset 

must  be  attached  to  each  toxic  or  combined  conventional/ 

toxic  weapon  attack 
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IV.  AURA  INPUT  COMMANDS  and  OPTIONS 


A.  ASSET  INPUTS 

The  following  data  sets  input  parameters  that  describe  the  assets  (personnel 
and  equipment)  of  a  unit. 

1.  ALARM.  This  command  identifies  both  vapor  dosage  sensitive  and  vapor 
concentration  sensitive  chemical  alarms  and  indicates  threshold  for  activation  due 
to  each  weapon.  The  user  must  designate  a  threshold  value  of  <  0  to  indicate  a 
vapor  concentration  sensitive  alarm  and  a  value  >  0  to  specify  a  vapor  dosage 
sensitive  alarm. 

Format: 

ALARM 

asset  name  of  alarm  (as  defined  in  NAMES  input) 

weapon  namel,  threshold  dosage  for  alarm  to  sound  (REAL)  (Default:  0.0) 
weapon  name2,  threshold  dosage  .... 


NOTE: 

Toxic  dissemination  data  (UNIT  #4)  must  be  read  in  first  to  allow 
the  code  to  adjust  for  dose  normalization  (see  TOXIC  DISPERSION 
DATA,  p.  42).  Alarms  are  deployed  by  asset  name  like  any  other 
equipment  (see  DEPLOYMENT,  p.  22).  Alarms  will  have  no  effect 
(will  be  too  late)  if  personnel  begin  to  MOPP-up  as  soon  as  round 
arrives.  Must  use  ROUND  NO  option  (see  MOPP,  p.  24). 

2.  CONTAMINATED  USAGE.  This  command  allows  designating  those 
items  of  equipment  which  may  be  used  when  contaminated,  along  with  the  mis¬ 
sions  (CHAINs)  in  which  this  usage  is  allowed. 

Format: 

CONTAMINATED  USAGE 

asset  name,  CHAIN  numbers  (INTEGERS) 


NOTE  1: 

If  contaminated  usage  card  is  not  included  in  a  runstream  for  which 
a  toxic  event  occurs,  contaminated  items  of  equipment  will  be  used 
ps  long  as  personnel  are  in  MOPP4. 


NOTE  2: 

If  CHAIN  numbers  are  omitted,  all  CHAINs  are  assumed. 
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Option  1: 

If  asset  name  is  "ALL",  all  assets  become  contaminated-usable. 

Option  2: 

If  MUST  MOPP  ON,  contaminated  items  usable  only  if  all  personnel  in 
a  safe  posture. 

Format: 

MUST  MOPP  ON 

MUST  MOPP  OFF  (Default:  OFF) 

3.  EXPENDABLE.  This  command  identifies  assets  that  are  expended  as  they 
are  used.  Two  forms  are  available:  Expenditure  by  time  and  expenditure  by 
repair  completion. 

EXPENDABLE 


Option  1: 

expenditure  by  time: 

Format: 

asset  name,  rate  of  usage  by  time  (per  minute)  (REAL) 
Option  2: 

expenditure  by  repair  completion: 

Format: 

Sasset  name 


NOTE  2: 


For  assets  identified  as  expendable  under  option  1,  the  amount  that  is 
assessed  as  expended  at  any  time  point  depends  upon  the  amount  of 
mission  time  spent  since  the  previous  update  and  the  effectiveness  of 
the  unit  during  that  time.  (Mission  time  is  that  time  which  follows  a 
reconstitution  and  extends  until  interrupted  by  a  lethality  event.) 
Assets  identified  as  expended  during  repair  or  decontamination  act¬ 
ivities  must  have  HOMELINKs  which  appear  in  the  consuming  repair 
SUBCHAINs  (see  REPAIR,  p.  18).  LINK  parameters  should  describe 
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4.  FAILURE  RATE.  This  command  specifies  the  rate  at  which  'ets  undergo 
spontaneous  (reliability-type)  failures.  Equipment  can  fail  so  as  tc  jquire  light, 
medium,  or  infeasible  repair;  personnel  can  only  have  dead  failures. 

Format: 

FAILURE  RATE 

asset  name,  mtbf,  fl,  fn* 

where: 

mtbf  is  the  mean  time  (intrvl)  between  any  failures  (REAL) 
fl  is  the  fraction  of  failures  requiring  light  repair  (REAL) 

fm  is  the  fraction  requiring  medium  repair  (REAL) 

NOTE  2: 

If  fl  and  fm  are  not  specified,  all  failures  are  taken  as  dead. 

Option  1: 

Preload  pool  of  ongoing  repairs  at  time  0: 

Format: 

PREFAIL, ON 

NOTE  3: 

When  PREFAIL  is  ON  (the  default  case),  light  and  medium  repairs  are 
prestarted,  simulating  an  ongoing  process  at  the  initial  time  of  the  study. 
This  option  avoids  having  too  many  items  available  at  time  zero,  too 
many  failing  afterwards,  and  a  delay  in  the  repair  return  rate. 

Option  2: 

If  mtbf  is  entered  as  a  negative  number,  the  value  of  mtbf  is  taken  as  a 
probability  of  not  being  present  at  time  0.  Requires  PREFAIL  option 
to  be  ON. 

5.  GRANULARITY.  This  command  causes  the  iterative  portion  of  the 
optimal  allocation  processor  to  consider  allocating  an  asset  in  specified  portions, 
thus  decreasing  the  possibility  of  over-allocating  to  one  task  at  the  detriment  of 
others.  Since  the  optimization  algorithm  has  built-in  checks  against  such  over¬ 
allocation,  this  command  is  used  to  allocate  an  asset  to  more  than  one  job. 
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Format: 


GRANULARITY 
asset  name,  grnl 

where: 

grnl  is  the  largest  increment  per  allocation  step  (REAL)  (Default:  1.0) 

6.  REINFORCEMENTS/LOSSES.  This  command  causes  specified  assets 
(pe'sonnel  or  equipment)  to  appear/disappear  at  specified  times  in  an  encounter. 
This  command  has  been  used,  for  example,  in  a  detailed  study  in  which  an  a 
priori  decision  to  reinforce/remove  some  assets  at  a  point  in  the  encounter  was 
part  of  the  scenario. 

Format: 

REINFORCEMENTS 
TIME,  time  of  event 
$asset  name,  number  gained 
$asset  name,  number  gained 
•  •• 

$asset  name,  number  gained 
$asset  name,  number  g  lined 
TIME,  time  of  event 
$asset  name,  number  gained 
lasset  name,  number  gained 


or 


LOSSES 

TIME,  time  of  event 
$asset  name,  number  lost 
$asset  name,  number  lost 


where: 

time  is  the  (clock)  time  of  reinforcement  (REAL) 
number  is  the  number  of  assets  added/removed  (INTEGER) 

NOTE: 

LOSSES  can  only  remove  assets  which  have  survived  to  the  time  of  removal. 
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7.  REPAIR.  This  command  inputs  data  relative  to  the  repair  of  damaged  or 
failed  equipment.  Included  in  the  inputs  are  the  subtasks  (LINKs  or  SUB- 
CHAINs)  needed  for  repair,  the  mean  time  and  standard  deviation  in  the  mean 
time  for  repair,  and  the  penalty  (0.0  -  1.0)  that  the  commander  would  be  willing 
to  take  in  his  immediate  mission  in  order  to  fix  the  item  if  the  need  for  the  item 
were  the  choke  point  in  the  missioi .  AURA  also  uses  the  penalty  value  to  help 
prioritize  possible  repairs  at  various  levels. 

Reoairs  can  be  specified  on  three  levels:  0  =  decontamination  needed, 
1  =  light  repair  needed,  and  2  =  medium  repair  needed.  It  is  assumed  that  light 
or  medium  repair  can  be  applied  to  the  specified  item  regardless  of  the  source  of 
need  i.e.  either  failure  or  combat  damage.  See  FAILURE  RATE,  p.  16,  for 
specification  of  equipment  failures. 

NOTE: 

Repairable  combat  damage  requires  both  that  the  item  appear  as  a 
repairable  under  this  mnemonic  and  that  the  item  has  exactly  three 
kill  criteria  specified  in  the  lethality  file. 

Format: 

REPAIR 
asset  name 

$cpl,lvll,pnltl,mtl,sdl,xrpl,yrpl 

$cp2,lvl2,pnlt2,... 


where: 

cpI 

Ivll 

pnltl 

mtl 

sdl 

xrpl 

and 

yrpl 


is  the  LINK  or  SUBCHAIN  needed  to  perform  level  I  repair  on 
the  named  asset 

is  the  level  of  repair  being  described  (INTEGER) 
is  the  acceptable  mission  penalty  for  level  I  repair  (REAL) 
is  the  mean  time  to  accomplish  level  I  repair  (REAL) 
is  the  standard  deviation  in  mtl  (REAL) 

are  the  coordinates  of  the  location  at  which  repair  of  this  item 
at  this  level  would  take  place  (REAL) 


NOTE: 

If  an  asset  name  for  which  multi  levels  of  damage  are  assessed  is  not 
followed  by  repair  card(s),  a  warning  is  printed.  AURA  then  ass¬ 
umes  that  the  user  wants  combat  damage  levels  checked  and  tallied, 
but  knows  that  there  is  no  repair  available. 
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Option  1: 

GENERAL  REPAIR.  This  option  allows  specification  of  general  repair 
LINKs  or  SUBCHAINs,  i.e.  capabilities  which  must  be  satisfied  ONCE 
in  order  for  any  repairs  to  be  conducted. 

Format: 

GENERAL  REPAIR 
$gnrl  cp,  lvl 

where: 

gnrl  cp  is  the  LINK  or  SUBCHAIN  needed  for  any  repair  at  level  lvl 
lvl  is  the  level  for  which  gnrl  cp  applies  (INTEGER) 

Optica  1: 

MAXIMUM  NUMBER.  This  option  allows  specifying  the  maximum 
number  of  repairs  which  can  be  going  on  at  any  time. 

Format: 

MAXIMUM  NUMBER,  maxrp 
where: 

maxrp  is  the  maximum  number  of  repairs  that  can  be  ongoing  at  any  one 
time  (INTEGER).  Default:  maxrp  =  50 


Option  2: 

NO  REPAIR.  This  option  allows  specifying  those  CHAINs  in  which  no 
repair  or  decontamination  is  allowed. 


NOTE: 

CHAIN  input  must  precede  REPAIR  input  if  this  option  is  used. 
Format: 

NO  REPAIR,nchl,nch2,nch3,... 
where: 

nchl  are  the  CHAINs  which  do  not  allow  repair  or  decontamination. 
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8.  SECONDARY  EXPLOSIVE,  This  command  allows  identifying  some 
assets  as  being  potential  sources  of  secondary  explosions  (i.e.  being  detonated  by 
an  incoming  round  and  becoming  additional  lethality  sources  themselves).  To  use 
this  command,  the  "explosive  potential"  is  given  a  name  (e.g.  AMMO  STACK, 
SECONDARY)  which  appears  in  the  NAMES  list  as  both  an  ASSET  and  a 
WEAPON.  Similarly,  the  name  appears  in  the  conventional  lethajity  file  (see 
Appendix  B  of  Volume  2  of  the  AURA  Programmer/Analyst  Guide)1  as  both  a 
target  for  other  warheads,  where  data  describes  probability  of  detonation,  and  as 
a  warhead,  where  data  describes  the  effect  of  a  detonation  against  all  other  tar¬ 
gets  in  the  unit.  This  command  is  used  to  associate  the  "explosive  potential"  with 
the  appropriate  (real)  assets  (e.g.  ammunition  stacks). 

Format: 

SECONDARY  EXPLOSIVE 

secondary  explosive  name,  associated  assetl, .... 

9.  TEMPORARY  LOSSES/RETURN  TO  DUTY.  This  command  causes 
specified  assets  (personnel  or  equipment)  to  ’temporarily’  disappear/reappear  at 
specified  times  in  an  encounter.  This  command  has  been  used,  for  example,  in  a 
detailed  study  in  which  an  a  priori  decision  to  ’temporarily’  remove/replace  some 
assets  at  a  point  in  the  encounter  was  part  of  the  scenario. 

NOTE: 

TEMPORARY  LOSSES  command  is  identical  to  LOSSES,  except  lost 
assets  are  put  into  a  ’temporary  storage  area’. 

RETURN  TO  DUTY  command  is  identical  to  REINFORCEMENTS, 
except  assets  must  come  from  the  ’temporary  storage  area’.  That  is, 
the  assets  must  have  been  prior  TEMPORARY  LOSSES. 

TEMPORARY  LOSSES  can  only  remove  assets  which  have  survived 
to  the  time  of  removal.  Thus,  although  an  asset  may  be  marked  for 
TEMPORARY  LOSS,  it  might  not  be  put  in  the  ’temporary  storage 
area’  if  it  had  previously  been  killed.  For  such  assets,  RETURN  TO 
DUTY  has  no  effect. 


11.  R.  Sheroke,  et  al , Programmer /Analyst  Guide  for  the  Army  Unit  Resiliency  Analysis 
(AURA)  Computer  Simulation  Model,  Volume  S:  AURA  Souree  Code,  USA  Ballistic 
Research  Laboratory,  BRL-TR-3103,  (JUL  90),  (UNCLASSIFIED). 
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Format: 


TEMPORARY  LOSSES 
TIME,  time  of  f'vent 
Sasset  name,  number  lost 
Sasset  name,  number  lost 

Sasset  name,  number  lost 
Sasset  name,  number  lost 
TIME,  time  of  event 
Sasset  name,  number  lost 
Sasset  name,  number  lost 

RETURN  TO  DUTY 
TIME,  time  of  event 
Sasset  name,  number  returned 
Sasset  name,  number  returned 


where: 

time  is  the  (clock)  time  of  reinforcement  (REAL) 

number  is  the  number  of  assets  ’temporarily’  removed/returned  (INTEGER) 

10.  TIREDNESS.  This  command  enables  the  user  to  control  the  levels  (in 
SLUNITs)  at  which  an  asset  is  allowed  to  stop  working  and  rest.  Recall:  1 
SLUNIT  =  1  minute  of  effective  rest. 

Format: 

TIREDNESS 
asset  name 
SMIN  (REAL) 

SMAX  (REAL) 

$DUR  (REAL) 

$CEI  (REAL) 

$INI  (REAL) 

where: 

$MIN  -  minimum  SLUNITs  below  which  assets  will  be  forced  to  rest 
(Default:  0.0) 

$MAX  -  maximum  SLUNITs  above  which  assets  may  not  rest 
(Default:  (1520.0  -  0.01)  =  1518.89) 

$DUR  -  minimum  duration  of  rest  (Default:  240.0) 

$CEI  -  ceiling  on  the  number  of  cumulative  SLUNITs  (Default:  1520.0) 
$INI  -  initial  SLUNITs  for  asset  at  start  of  each  replication 
(Default:  1520.0) 
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B.  DEPLOYMENT  INPUTS 


The  following  data  sets  input  parameters  related  to  particular  (geographi¬ 
cal)  deployment  points.  Note  that  this  also  includes  data  that  define  codes  for 
any  status  that  is  location  dependent  (like  MOPP  posture)  and  also  data  which  is 
associated  to  that  status  (such  as  degradation  due  to  MOPP  posture). 

1.  DEGRADATION.  This  command  allows  the  user  to  associate  a  MOPP 
code  number  and  a  TOXIC  KILL  CRITERIA  (T.K.C.)  code  number  with  a  per¬ 
formance  degradation  value.  When  the  code  is  evaluating  the  effectiveness  of 
individuals  in  specified  tasks,  it  degrades  the  contributions  according  to  the 
current  MOPP  posture  and  the  T.K.C.  of  the  deployment  point.  Thus,  the 
degradation  of  a  job  due  to  the  wearing  of  MOPP  is  input  via  the  T.K.C.  and 
toxic  posture  (and  alternate  toxic  posture,  if  used)  (see  DEPLOYMENT,  p.  22 
and  T.K.C.,  p.  28). 


Format: 

DEGRADATION 
MOPP  code,  tkc,  dgf 

where: 

MOPP  code  is  defined  under  the  MOPP  command  (see  p.  24)  (INTEGER) 
(Default:  4) 

tkc  is  defined  under  the  T.K.C.  command  (see  p.  28)  (INTEGER) 

(Default:  1) 

dgf  is  the  degradation  factor  for  the  specified  MOPP  posture  and 

job  difficulty  (T.K.C.)  (REAL) 

2.  DEPLOYMENT.  This  command  indicates  location,  number,  "kill  criteria" 
and  posture  of  assets.  A  supplementary  continuation  line  may  be  used  to  indicate 
alternate  postures  and  times-to-change-posture.  This  command  is  also  used  to 
locate  places  at  which  dummylink  jobs  would  be  done  (see  DUMMYLINK,  p.  7). 
Each  set  of  data  defines  a  TARGET  POINT. 

Format: 

DEPLOYMENT 

asset  name,  x,  y,  nmbr,  ckc,  nkc,  tkc,  cpst,  npst,  tpst 
where: 

asset  name  is  "unique"  name  of  asset  or  DUMMYLINK  at  target  point 
x,  y  are  coordinates  in  unit  coordinate  system  (REAL) 
nmbr  is  the  number  of  (identical)  assets  at  the  point  (REAL) 
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ckc  is  the  conventional  kill  criteria  code  (INTEGER)  (see  APPEN¬ 
DIX  B  of  Volume  2)12 

nkc  is  the  nuclear  kill  criteria  code  (INTEGER) 

tkc  is  the  toxic  kill  criteria  code  (INTEGER)  (see  T.K.C.,  p.  28) 

cpst  is  the  conventional  posture  code  (INTEGER) 

npst  is  the  nuclear  posture  code  (INTEGER)  (see  SHIELDING,  p.  27) 

tpst  is  the  toxic  posture  code  (INTEGER)  (see  MOPP,  p.  24) 

Option  1: 

Alternate  posture 

Format: 

$cpst,npst,timel  or 
$tpst,tirae2  or 
$cpst,  npst,  timel,  tpst,  time2 

where: 

cpst  is  the  alternate  conventional  posture  (INTEGER) 

npst  is  the  alternate  nuclear  posture  (INTEGER) 

timel  is  the  mean  time  (intrvl)  required  to  change  to  cpst, npst  (REAL) 

tpst  is  the  alternate  toxic  posture  (INTEGER) 

time2  is  the  time  (intrvl)  needed  to  change  to  tpst  (REAL) 

NOTE  1: 

If  cpst,  npst,  and  tpst  are  specified,  conventional,  nuclear  and  toxic 
posture  change  begins  at  arrival  of  first  round. 

NOTE  2: 

Toxic  posture  change  may  also  be  initiated  by  the  ALARM  command 
(see  p.  14). 

Option  2: 

MOPP  ALL.  This  option  provides  a  short  cut  to  give  all  personnel  the 
same  alternate  MOPP  posture  with  the  same  mean  time  to  change  such 
that  the  individual  times- to- change  are  normally  distributed.  The  TIME 
SPREAD  option,  p.  25,  can  be  used  to  vary  the  sigma  associated  with 
this  distribution. 


12. Ibid. 
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Format: 


MOPP  ALL,  tpst,  time2 
NOTE  3: 

The  MOPP  ALL  card  can  be  inserted  anywhere  in  the  deployment  input 
set.  If  used,  it  supersedes  any  individual  alternate  MOPP  postures. 

Option  3: 

\OFFSET.  This  option  allows  adding  specified  values  to  the  x  and  y 
coordinates  of  all  deployment  points  which  follow  in  the  runstream. 

This  option  provides  an  easy  method  of  displacing  a  section  of  a  dep¬ 
loyment.  As  denoted  by  the  leading  backslash,  this  is  an  embedded 
procedure  command  (see  p.  6). 


Format: 

\OFFSET,  x-displacement  (REAL),  y-displacement  (REAL) 

NOTE  4: 

The  offset  generated  within  the  DEPLOYMENT  command  is  ADDITIVE 
to  the  offset  generated  by  the  \OFFSET  command  or  by  the  \OFFSET 
card  in  the  execution  runstream. 

3.  MOPP.  This  command  allows  the  user  to  define  the  toxic  posture  (MOPP) 
codes  (used  in  DEPLOYMENT  for  initial  and  alternate  toxic  posture)  and  specify 
a  penetration  factor  for  each.  The  penetration  factor  is  used  to  adjust  the  dosage 
received  by  an  individual  or  contamination  received  by  a  piece  of  equipment  for 
an  asset  in  the  specified  toxic  posture.  This  command  is  also  used  to  set  a 
number  of  options  dealing  with  the  assumption  of  alternate  MOPP  posture. 

Format: 

MOPP 

verbal  description  (<13  characters),  tpst,  tfv,  tfp 
where: 

tpst  is  the  toxic  posture  code  number  (INTEGER) 
tfv  is  the  fraction  of  vapor  dosage  still  received  in  posture  (REAL) 
Defaults:  MOPPO  -  MOPP2  =  1.0,  MOPP3,  MOPP4  =  0.0 
tfp  is  the  fraction  of  percutaneous  dosage  still  received  in  posture  (REAL) 
Defaults:  MOPP0=1.0,  MOPPi=0.2,  MOPP2=0.1,  MGrP3=G.02G, 
MOPP4=0.0 

If  tfp  is  not  given,  tfp  is  set  to  tfv. 
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NOTE: 

Codes  0  -  4  default  to  "OPEN",  "MOPPl",  "MOPP2",  etc.,  with 
penetrations  decreasing  from  1.0  to  0.0. 

Options: 

These  optional  commands  enable  the  user  to  customize  MOPP  con¬ 
ditions  throughout  the  AURA  run. 

Format: 

ALL  CLEAR, YES  or  ALL  CLEAR, NO.  This  option  automatically  returns 
unit  individuals  to  initial  MOPP  posture  when  the  last  contaminant  evap¬ 
orates  or  is  removed  by  decontamination.  Default:  ALL  CLEAR, YES 

PROXIMITY,  dist  (REAL).  This  option  allows  specifying  the  (x  and  y)  dis¬ 
tance  from  a  warhead  within  which  an  asset  must  be  in  order  to  "feel  threat¬ 
ened"  by  an  incoming  round  and  change  MOPP  posture  (see  ROUND  YES, 
immediately  below).  Default:  dist  =  1.E35 

RECONSTITUTION, YES  or  RECONSTITUTION, NO.  This  option  causes 
the  unit  status  to  be  output  for  each  reconstitution. 

Default:  RECONSTITUTION, NO 

RECOVERY  TIME,  trcvr  (REAL).  This  option  inputs  the  time,  in  minutes 
(intrvl),  needed  to  realize  that  contamination  is  no  longer  present  and  to 
resume  initial  MOPP  posture.  Default:  trcvr  =  30.0 

ROUND, YES,  tfalse  (REAL)  or  ROUND, NO.  This  option  controls  whether 
individuals  assume  alternate  MOPP  posture  upon  any  incoming  round.  If 
ROUND  YES,  the  value  tfalse  is  the  (false  alarm  recognition)  time,  minutes 
(intrvl),  needed  to  recognize  that  none  of  the  incoming  rounds  were  toxic 
and  to  return  to  initial  MOPP  posture.  Default:  ROUND, YES,  tfalse  =  10.0 

NOTE: 

ROUND, NO  must  be  used  when  modeling  the  ALARM  command. 

TIME  SPREAD,  sigma  (REAL).  This  option  inputs  the  fractional  standard 
deviation  in  time  needed  to  change  MOPP  posture  when  MOPP  ALL  command 
is  used.  Default:  sigma  =  0.2 
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4.  \OFFSET.  This  command  reads  x  and  y  offset  values  which  are  added  to 
the  x  and  y  coordinates  of  every  deployment  point  before  the  analysis  commences. 
This  allows  the  user  to  model  one  generic  deployment  of  a  unit,  centered  around 
0.,0.  and  displace  the  entire  deployment  to  specific  (battlefield)  locations. 

Format: 

\OFFSET 

x-offset  (REAL),  y-offset  (REAL)  in  UNIT  coordinate  system 
NOTE: 

Offsets  can  also  be  input  via  the  computer’s  normal  input  channel  as  part 
of  program  execution.  In  case  of  conflict,  offsets  input  via  the  execution 
stream  take  precedence  (see  EXECUTION,  p.  3).  The  offset  input  via  this 
command  or  via  the  execution  stream  is  *  additive  *  to  any  offset  input 
via  the  \OFFSET  option  under  DEPLOYMENT  (see  p.  24). 

5.  REST.  This  command  specifies  the  location  at  which  personnel  assets  deploy 
when  assigned  to  rest  (see  FATIGUE,  p.  43).  If  no  rest  location  is  specified  for  an 
asset,  it  is  assumed  that  the  asset  will  rest  at  his  duty  station. 

Format: 

REST 

asset  name,  x,  y,  ckc,  nkc,  tkc,  cpst,  npst,  tpst 
Option: 

Alternate  postures 

Format: 

$cpst,npst,timel 

or 

$tpst,time2 

or 

$cpst,  npst,  timel,  tpst,  time2 
NOTE: 

See  DEPLOYMENT,  p.  22,  for  definition  of  data.  This  input  is  identical  to 
DEPLOYMENT  except  nmbr  is  omitted  and  asset  name  need  not  be  unique. 
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6.  SHIELDING.  This  command  allows  the  user  to  define  nuclear  posture  code 
numbers.  Shielding  associates  a  verbal  description  and  a  transmission  matrix  with 
the  code  number.  (See  Appendix  B  for  default  shielding  values.) 

Format: 

SHIELDING 

verbal  description,  npst,  trnsl,  trns2,  trnsS,  trns4 
where: 

npst  is  the  code  number  (INTEGER,  between  4-61)  and  the  transmission 
factors  are  defined  by: 

trnsl  =  (n,n) 

trns2  =  (g,n)  (usually  =  0) 
trns3  =  (n,g) 
trns4  =  (g,g) 

where: 

n  indicates  neutron 

g  indicates  gamma 

(a,b)  indicates  dosage  of  type  b  in  the  posture  due  to  an  incident 
dosage  of  type  a.  (REAL) 

NOTES: 

If  only  trnsl  is  given,  it  is  used  for  trnsl  and  trns4;  trns2  and  trns3 
are  set  =  0.  Nuclear  posture  codes  1,  2  and  3  are  reserved  for  OPEN, 
OPEN-BUT-THERMALLY-SHIELDED  and  FOXHOLE,  respectively. 

No  vehicle  can  be  associated  with  posture  codes  1-3.  Codes  4  and  5 
default  to  APC  and  TANK;  however,  the  user  must  associate  any 
vehicular  blast  protection  (see  following  option). 

Option: 

An  asset  (usually  a  vehicle)  can  be  associated  with  nuclear  posture 
codes  4  through  61.  Doing  so  gives  an  individual  in  the  pasture  the 
same  blast  criteria  as  the  associated  vehicle.  That  is,  the  personnel 
assets  in  the  vehicle  will  be  considered  casualties  when  the  vehicle 
becomes  a  casualty. 

Format: 

Sassociated  asset  name 
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7.  T.K.C.  (TOXIC  KILL  CRITERIA).  This  command  allows  the  user  to 
define  the  toxic  kill  criteria  code  numbers.  T.K.C.  associates  with  the  code 
number  a  verbal  description  and  a  chemical  dosage  multiplier  (used  to  simulate 
higher  (or  lower)  than  normal  ratio  of  dose/dosage,  as  would  be  acquired  by  a 
person  whose  task  required  a  higher  (or  lower)  than  normal  breathing  rate).  The 
effect  of  the  TOXIC  KILL  CRITERIA  code  number  in  general,  and  this  option  in 
particular,  is  to  allow  the  user  to  indicate  deployment  points  at  which  a  difficult 
(or  easy)  job  is  being  done.  Any  individual  assigned  to  that  deployment  point 
inherits  the  criterion  of  the  job  (see  also  DEGRADATION,  p.  22). 

Format: 

T.K.C. 

verbal  description  (<i3  characters),  tkc,  dm 

where: 

tkc  is  the  toxic  kill  criteria  code  number  (INTEGER,  1-20) 

Default:  4 

dm  is  the  dosage  multiplier  (relative  to  breathing  rate)  (REAL) 

Default:  1.0 
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C.  WEAI  ON  INPUTS 


The  following  input  parameters  relate  to  weapon  delivery  system  perfor¬ 
mance  and  weapon  arrival  events. 

1.  ACQUISITION  PROBABILITY.  This  command  inputs  a  single  probabil¬ 
ity  number  which  represents  the  probability  that  the  unit  has  been  acquired. 
This  command  also  allows  a  change  in  probability  via  a  change  event.  A  random 
number  is  drawn  against  the  current  probability  value  and  the  acquisition  status 
is  redetermined  at  the  beginning  of  every  replication  and  upon  every  change 
event.  Before  every  lethality  event,  acquisition  :tatus  is  checked:  if  in  a  non- 
acquired  state,  lethality  events  are  skipped. 

Format: 

ACQUISITION  PROBABILITY 
pacqr 

where: 

pacqr  is  the  target  acquisition  probability  (REAL)  (pacqr  must  be  a 
value  between  0.0  and  1.0  inclusive.)  Default:  1.0 

Option: 

This  option  can  be  used  to  input  an  ACQUISITION  PROBABILITY 
change  event.  This  allows  the  user  to  simulate  a  point  in  time  at 
which  the  probability  of  target  acquisition  changes,  as  would  be  caused 
by  unit  movement.  It  also  causes  a  new  random  number  to  be  drawn. 
Thus,  to  model  independent  attacks  on  parts  of  a  separated  unit,  use  of 
this  option  will  cause  acquisition  probabilities  to  be  uncorrelated. 

Format: 

time,  pacqr 

where: 

time  is  the  (clock)  time  at  which  the  change  in  error  occurs  (REAL) 

2.  AGENT.  This  command  associates  a  toxic  agent  type  with  a  specific 
weapon. 

Format: 


weapon  name,  atyp 
where: 

atyp  is  G,  V,  or  H.  Default:  atyp  =  G 


3.  CEP  ERROR.  This  c<  mmand  reads  delivery  errors  expressed  in  circular 
error  probable  (CEP).  (CEP  ERROR  is  that  radius  within  which  one  half  of  the 
rounds  are  expected  to  fall.) 

Format: 

CEP  ERROR 

weapon  name,  indcep,  corcep,  hob 

where: 

indcep  is  the  independent  round  error,  also  known  as  the  precision  er¬ 
ror  (REAL)  Default:  0.0 

corcep  is  the  volley-correlated  circular  error,  also  known  as  the  mean 
point  of  impact  (MPI)  error  (REAL)  Default:  0.0 
hob  is  the  standard  deviation  in  height-of-burst  (REAL) 

Default:  0.0 

IMPORTANT  NOTE: 

Values  of  errors  >  0  result  in  errors  being  drawn  from  a 
Gaussian  distribution  having  a  shape  parameter  derived 
from  the  input  error  value.  Values  <  0  result  in  errors 
being  drawn  from  a  uniform  distribution  having  a  range 
parameter  derived  from  the  ir put  error  value.  Positive 
and  negative  values  may  be  mixed  on  the  same  card. 


Option: 

This  option  can  be  used  to  input  a  CEP  ERROR  change  event. 
This  allows  the  user  to  simulate  a  point  in  time  at  which  the 
error  in  incoming  fire  changes,  as  would  be  caused  by  a  change 
in  location  of  the  attack. 

Format: 

weapon  name,  time,  indcep,  corcep,  hob 
where: 

time  is  the  (clock)  time  at  which  the  change  in  error  occurs  (REAL) 
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4.  CEP  TLE.  This  command  inputs  target  location  errors  expressed  as  a  circu¬ 
lar  error  probable  (CEP).  (CEP  TLE  is  that  radius  within  which  the  target  is 
expected  to  be  one  half  of  the  time.) 

Format: 

CEP  TLE 
tlecep 

where: 

tlecep  is  the  target  location  error,  expressed  as  a  circular  error 
probable  (REAL)  Default:  0.0 


NOTE: 

See  CEP  ERROR,  p.  30,  for  choice  of  distributions. 

Option: 

This  option  can  be  used  to  input  a  CEP  TLE  change  event.  This  allows 
the  user  to  simulate  a  point  in  time  at  which  the  error  in  target  loca¬ 
tion  changes,  as  may  result  from  the  use  of  different  intelligence  sources. 

Format: 

time,  tlecep 

where: 

time  is  the  (clock)  time  at  which  the  change  in  error  occurs  (REAL) 

5.  DELIVERY  ERROR.  This  command  inputs  weapon  delivery  errors  as 
standard  deviations  or  radii  of  uniform  distributions  in  RANGE  and  DEFLEC¬ 
TION. 

Format: 

DELIVERY  ERROR 

weapon  name,  rind,  rcor,  dind,  dcor,  hob 

where: 

rind  is  the  independent  round  error,  also  known  as  the  precision 
error  in  range  (REAL)  Default:  0.0 
rcor  is  the  volley-correlated  error  in  range,  also  known  as  the 
mean  point  of  impact  (MPI)  error  (REAL)  Default:  0.0 
dind  is  the  independent  error  in  deflection  (REAL)  Default:  0.0 
dcor  is  the  volley-correlated  error  in  deflection  (REAL)  Default:  0.0 
hob  is  the  error  in  height-of- burst  (REAL)  Default:  0.0 
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NOTE: 

See  CEP  ERROR,  p.  30,  for  choice  of  distributions. 

Option: 

This  option  can  be  used  to  input  a  DELIVERY  ERROR  change 
event.  This  allows  the  user  to  simulate  a  point  in  time  at  which 
the  error  in  weapon  delivery  changes,  as  may  result  from  a  var¬ 
iation  in  the  weapon  system  to  target  range. 

Format: 

weapon  name,  time,  rind,  rcor,  dind,  dcor,  hob 
where: 

time  is  the  (clock)  time  at  which  the  change  takes  place  (REAL) 

6.  INCOMING  FIRE  DIRECTION.  This  command  orients  the  incoming  fire 
(RANGE)  direction  with  respect  to  the  unit  coordinate  system.  See  discussion  of 
coordinate  systems  on  p.  11. 

Format: 

INCOMING  FIRE  DIRECTION 
incang 

where: 

incang  is  the  angle  (degrees)  from  the  UNIT  x  direction  to  the  RANGE 
direction  (INTEGER,  positive  if  counter-clockwise). 

Default:  incang  =  0 


Option  1: 

Incoming  fire  direction  change  event. 

Format: 
time,  incang 
where: 

time  is  the  (clock)  time  at  which  the  incoming  fire  direction 
changes  (REAL). 


Option  2: 

The  incoming  fire  direction  can  also  be  specified  as  a  range  of 
directions,  in  which  case  the  code  will  randomly  select,  from  a 
uniform  distribution,  a  new  direction  within  the  specified  range 
for  each  replication. 


32 


Format: 


incangl, incang2 
where: 

incangl  and  incang2  are  the  angles  between  which  the  incoming  fire 
directions  will  lie  (INTEGERS) 


Option  3: 

Incoming  fire  direction  change  event,  specified  over  a  range  of  angles. 
Format: 

time,  incangl,  incang2 

7.  MISS  DISTANCE.  This  command  inputs  a  fixed  distance  by  which  a 
weapon  will  miss  its  aim  point.  Rounds  will  be  randomly  located  on  a  circle  of 
radius  ’miss  distance’  away  from  the  designated  burst  point.  Typically, 
DELIVERY  ERROR  or  CEP  ERROR  commands  would  not  be  used  in  conjunc¬ 
tion  with  MISS  DISTANCE. 

Format: 

MISS  DISTANCE 
weapon  name,  mdis,  hob 

where: 

mdis  is  the  miss  distance  (REAL) 

hob  is  the  error  in  height-of-burst  (REAL) 

NOTE: 

hob  is  optional.  If  used,  see  CEP  ERROR,  p.  30,  for  choice  of  distributions. 

8.  RELIABILITY  OF  WEAPONS.  This  command  causes  randomly  selected 
rounds  or  volleys  to  fail  according  to  a  uniform  distribution. 

Format: 

RELIABILITY  OF  WEAPONS 
weapon  name,  rrnd,  rvol 

where: 

rrnd  is  the  single  warhead  reliability  (REAL)  (Default:  1.0) 
rvol  is  the  reliability  of  volley  (REAL)  (Default:  1.0) 

NOTE:  If  only  one  value  is  given,  it  is  assumed  to  be  rrnd. 
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9.  ROUND.  This  command  inputs  the  parameters  necessary  to  specify  an 
attack  by  a  single  round. 

Format: 

ROUND 

weapon  name,  time,  apx,  apy,  apz 
where: 

time  is  the  (clock)  time-of-arrival  of  the  round  (REAL) 
apx  is  the  intended  x-coordinate  (unit  coordinate  system) 
apy  is  the  intended  y-coordinate  (unit  coordinate  system) 
apz  is  the  intended  height-of-burst  (REAL) 

NOTE: 

The  apz  variable  is  ignored  when  modeling  either  toxic  or 
scenarios. 

10.  TLE.  This  command  reads  target  location  errors  expressed  as  standard 
deviations. 

Format: 

TLE 
tlex,  tley 

where: 

tlex  is  the  x-coordinate  of  the  target  location  error  (REAL) 

Default:  0.0 

tley  is  the  y-coordinate  of  the  target  location  error  (REAL) 

Default:  0.0 


(REAL) 

(REAL) 


nuclear 


NOTE: 

See  CEP  ERROR,  p.  30,  for  choice  of  distributions. 

Option: 

This  option  can  be  used  to  input  a  TLE  change  event.  This  allows 
the  user  to  simulate  a  point  in  time  at  which  the  error  in  target 
location  changes,  as  would  be  caused  by  unit  movement. 

Format: 


time,  tlex,  tley 
where: 

time  is  the  (clock)  time  at  which  the  change  in  error  will  occur  (REAL) 
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11.  VOLLEY.  This  command  inputs  parameters  necessary  to  specify  an  attack 
by  a  volley  of  weapons.  The  intended  pattern  is  assumed  to  be  a  line  of  the 
specified  width  and  at  the  specified  angle  with  respect  to  the  incoming  fire  direc¬ 
tion.  A  cluster-type  munition  (scatter  about  a  single  point)  can  be  modeled  by 
specifying  a  volley  pattern  width  of  0. 

Format: 

VOLLEY 

weapon  name,  time,  papx,  papy,  papz,  nrd,  ang,  width 
where: 

time  is  the  (clock)  time  of  the  attack  (REAL) 
papx  is  the  intended  x-coordinate  of  the  pattern  midpoint  (REAL) 
papy  is  the  intended  y-coordinate  of  the  pattern  midpoint  (REAL) 
papz  is  the  intended  height-of-burst  of  the  rounds  (REAL) 
nrd  is  the  number  of  rounds  in  the  volley  (INTEGER) 
ang  is  the  angle  (degrees)  of  the  pattern  line  with  respect  to  the 
incoming  fire  direction.  (REAL) 
width  is  the  width  of  the  pattern  line  (REAL) 

NOTE: 

The  papz  variable  is  ignored  when  modeling  either  toxic  or  nuclear 
scenarios. 

Option: 

This  option,  used  after  a  normal  volley  data  card  (above),  creates  multiple 
volleys  with  the  specified  time  between  volleys,  each  one  "stepped"  in  the 
specified  direction  by  the  specified  distance.  This  option  allows  easy 
modeling  of  a  moving  barrage. 

Format: 

$  nvol,  dtm,  dir,  dis 
where: 

nvol  is  the  number  of  additional  volleys  (INTEGER) 
dtm  is  the  time-between-volleys  (intrvl)  (REAL) 

dir  is  the  angle  (degrees)  of  movement  of  the  intended  pattern  midpoint 
measured  counter-clockwise  from  the  x  direction  (in  the  unit  coordin¬ 
ate  system)  (REAL) 

dis  is  the  distance  between  volley  midpoints  (REAL) 
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12.  WIND  DIRECTION.  This  command  orients  the  wind  (RANGE)  direction 
with  respect  to  the  unit  coordinate  system.  See  discussion  of  coordinate  systems 
on  p.  11. 

Format: 

WIND  DIRECTION 
windang 

where: 

windang  is  „he  angle  from  the  UNIT  x  direction  to  the  RANGE 
direction  (INTEGER,  positive  if  counter-clockwise). 

Default:  windang  =  0 

Option  1: 

This  option  permits  the  specification  of  a  wind  direction  change  event. 
Format: 
time,  windang 
where: 

time  is  the  (clock)  time  at  which  the  wind  direction  changes  (REAL) 
Option  2: 

The  wind  direction  can  also  be  specified  as  a  range  of  angles,  in  which 
case  a  new  wind  direction  is  randomly  selected,  from  a  uniform  dist¬ 
ribution,  within  the  specified  range  for  each  replication. 

Format: 

windangl,  windang2 
where: 

windangl  and  windang2  are  the  angles  within  which  the  wind 

direction  will  lie  (INTEGERS) 


Option  3: 

This  option  enables  the  combination  of  options  1  and  2  by  allow¬ 
ing  the  user  to  specify  the  time  at  which  the  range  of  wind  dir¬ 
ection  angles  will  be  selected. 

Format: 

time,  windangl,  windang2 
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13.  YIELD.  This  command  inputs  the  yield  of  nuclear  weapons. 
Format: 

YIELD 

weapon  name,  yldl,  yld2 
where: 

yldl  is  the  blast  and  thermal  yield  in  kilotons  (kt)  (REAL) 
yld2  is  the  effective  radiative  and  EMP  yield  in  kt  (REAL) 

NOTE: 

If  only  yldl  is  given,  it  is  used  for  both  yldl  and  yld2. 
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D.  WEAPON  EFFECTS 


The  following  data  establishes  input  and  output  parameters  relating  to 
weapon  effects. 

1.  CONVENTIONAL  LETHALITY  DATA.  This  command  causes  the 
AURA  code  to  read  a  conventional  lethality  data  file  via  input  unit  #2.  No 
further  data  is  needed  teee  Appendix  B  of  Volume  2  of  the  AURA 
Programmer /Analyst  Guide1**  for  the  format  of  the  conventional  lethality  data 
file). 

Format: 

CONVENTIONAL  LETHALITY  DATA 
NOTE: 

This  command  must  be  included  when  modeling  a  conventional  scenario. 

2.  DOSE  PARAMETERS.  This  command  allows  changing  various  parame¬ 
ters  which  control  the  personnel-response-to-dosage  algorithms  and  the  output 
report  of  dosages. 

Format: 

DOSE  PARAMETERS 
options 

Option  1: 

Set  values  for  dosage  "bins"  for  dosage  distribution  report  in  output. 
Format: 

DOSE  BINS,bl,b2,b3,b4,...blO 
where: 

bl,...,blO  are  the  median  values  of  each  dosage  bin.  (REAL) 

Defaults:  5.0,  75.0,  150.0,  300.0,  450.0,  530.0,  830.0,  1100.0, 

1500.0,  4500.0  (Nuclear)  (units  are  in  rads) 

.05,  .10,  .15,  .25,  .35,  .45,  .55,  ,65,  .75,  .85,  1.0 
(Toxic)  (units  are  normalized  to  casualty  criteria) 


13. Ibid. 


38 


NOTES: 

There  must  be  10  increasing  bin  values.  DO  NOT  input  bl  =  0.0; 
blO  may  =  MAX  DOSE,  but  may  not  exceed  it. 

Option  2: 

Set  maximum  dosage  to  be  considered  an  instant  casualty. 

Format: 

MAX  DOSE,  maximum  dosage  value  (REAL) 

Defaults:  8000.0  Gy  (Nuclear);  10.0  (Toxic) 

Option  3: 

Set  probit  slope  to  model  the  varying  sensitivity  of  individuals 
to  doses  of  various  chemicals. 

Format: 

PROBIT,  agent  number  (1,2,3)  (INTEGER),  probit  slope  value  (REAL) 

Defaults:  (The  defaults  represent  the  case  where  all  individuals  exhibit  the 
oame  response.) 


Agent  number 

.  Agent  type 

Default  slope 

1 

non-persistent 

0.0 

2 

persistent 

0.0 

3 

blistering 

0.0 

3.  INTRAVENOUS  DOSES.  This  command  enables  the  user  to  modify  the 
entry  rate  at  which  personnel  absorb  vapor  and/or  percutaneous  doses  from 
chemical  weapons.  The  methodology  (and  defaults)  behind  this  phenomena, 
known  as  route-of-entry,  is  described  in  Saucier’s  paper.14  The  defaults  represent 
the  case  where  the  multiple  route  of  entry  model  is  off. 

Format: 

IV  DOSE 
options 


14.  R.  Saucier,  A  Methodology  for  Calculating  the  Probability  of  Response  from  Multiple  Agent 
and  Multiple  Routes  of  Entry,  Studies  and  Analysis  Office,  US  Army  Chemical  Research  and 
Development  Center,  unpublished  paper,  (JUL  85),  (UNCLASSIFIED). 
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Option  1: 

This  command  enables  the  user  to  turn  the  multiple  route  of  entry  model 
Format: 

IVDOSE,  ON  or  OFF.  (Default:  OFF) 

Option  2: 

Format: 

INHALATION,  einhal  (REAL) 
where: 

einhal  is  the  exponential  parameter  for  transport  efficiency  of  inhalation 
Default:  einhal  =  1.0 


Option  3: 

Format: 

PERCUTANEOUS,  eperc  (REAL) 
where: 

eperc  is  the  exponential  parameter  for  transport  efficiency  of  percutaneous 
Default:  eperc  =  1.0 

4.  NUCLEAR  VULNERABILITY  DATA.  This  command  causes  the  AURA 
code  to  read  a  nuclear  vulnerability  data  file  via  input  unit  #3.  No  further  data 
is  nee^d  (see  Appendix  B  in  Volume  2  of  the  AURA  Programmer/ Analyst 
Guide  for  the  format  of  the  nuclear  vulnerability  data  file). 

Format: 

NUCLEAR  VULNERABILITY  DATA 
NOTE: 

This  command  must  be  used  when  modeling  a  nuclear  scenario. 


15.  R.  Sheroke,  et  al,  Programmer/Analyst  Guide  for  the  Army  Unit  Resiliency  Analysis 
(AURA)  Computer  Simulation  Model,  Volume  2:  AURA  Source  Code,  USA  Ballistic 
Research  Laboratory,  BRL-TR-3103,  (JUL  90),  (UNCLASSIFIED). 


5.  PERSISTENCE.  This  command  enables  the  user  to  modify  the  persistence 
time  for  chemical  agents  on  specified  assets  from  the  standard  (uniform)  per¬ 
sistence  time  produced  by  the  toxic  dissemination  code  (NUSSE).  The  change  is 
affected  by  specifying  the  ratio  of  time-to-evaporate/diffuse  from  the  asset  to 
time-to-evaporate  as  output  by  NUSSE. 

Format: 

'  PERSISTENCE 
weapon  namel 
assetl,  frcll 
asset2,  frc!2 


assetJ,  frcIJ 
weapon  name2 
assetl, frc21 


assetJ,  frcIJ 
etc. 

where: 

frcIJ  is  the  ratio  of  evap  time  for  agent  from  weaponl  on  the  assetJ  to 
the  NUSSE  output  evaporation  time  (REAL).  Default:  1.0 


NOTE: 

TOXIC  DISPERSION  DATA  command  must  precede  this  command. 

6.  THERMAL.  This  command  allows  the  user  to  specify  the  atmospheric  ther¬ 
mal  transmissivity  and  the  type  of  uniform  being  worn.  These  parameters  affect 
the  calculation  of  thermal  casualties. 

Format: 

THERMAL 

options 

Option  1: 

Thermal  transmissivity 
Format: 


ATMOSPHERE,  quality 


where: 

quality  must  be  GOOD,  AVERAGE,  or  POOR 
Default:  AVERAGE 
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Option  2: 

Type  of  uniform 

Format: 

UNIFORM,  type 
where: 

type  must  be  SUMMER  or  WINTER 
Default:  SUMMER 

7.  TOXIC  DISPERSION  DATA.  This  command  causes  the  AURA  model  to 
read  a  toxic  dispersion  data  file  via  input  unit  #4.  No  further  data  is  needed  (see 
Appendix  B  in  Volume  2  of  the  AURA  Programmer/Analyst  Guide10  for  the  for¬ 
mat  of  the  toxic  dispersion  data  file). 

Format: 

TOXIC  DISPERSION  DATA 
NOTE: 

This  command  must  be  used  when  modeling  a  chemical  scenario. 


E.  INDIVIDUAL  TASK  INPUTS 


The  following  input  parameters  model  specific  unit  tasks  and  alterations  to 
such  tasks  (e.g.,  task-dependent  degradations). 

1.  FATIGUE.  This  command  allows  the  user  to  specify  that  different  jobs 
(LINKs)  may  be  more  or  less  demanding  than  others,  both  in  terms  of  the  need 
for  personnel  to  be  rested  and  the  drain  upon  personnel  who  are  engaged  in  the 
job. 

Option  1: 

Format: 

FATIGUE 
link  name,  rfr,  rd 

where: 

rfr  is  the  relative  fatigue  rate  (REAL) 

Default:  0.2639  SLUNITs/minute 
rd  is  the  relative  demand-for-stored-rest  (REAL) 

Default:  1235.0  SLUNITs 


Option  2: 

Format: 

FATIGUE 

link  name,  rfr,  rd,  slpmn,  slpmx 
where: 

slpmn  is  the  minimum  amount  of  sleep  required  by  assets  in  link 
Default:  240.0  SLUNITs 

slpmx  is  the  maximum  amount  of  sleep  permitted  for  assets  in  link 
Default:  1520.0  SLUNITs 

17 

(See  section  IV.3  of  Volume  1  for  derivation  of  default  values.) 


17.  R.  Sheroke,  et  al,  Programmer/Analyst  Guide  for  the  Army  Unit  Resiliency  Analysis 
(AURA)  Computer  Simulation  Model,  Volume  1:  AURA  Methodology,  USA  Ballistic 
Research  Laboratory,  DRAFT  REPORT,  (AUG  90),  (UNCLASSIFIED). 
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2.  HEAT  STRESS.  This  command  enabies  the  user  to  specify  values  for  the 
various  meteorological  and  physiological  conditions  which  can  impact  heat  stress 
effects  on  personnel.  The  methodology  used  to  calculate  the  effects  of  these  condi¬ 
tions  is  based  upon  the  Goldman-Givoni  Model.1 

Format: 

HEAT  STRESS 
one  letter,  data  (REAL) 

These  letters/data  are: 

T,  start  time,  stop  time  of  meteorological  period 

This  is  followed  by  the  meteorological  parameters  for  the  period: 

$T,  ambient  temperature  (degrees  Celsius)  (Default:  20.0) 

$H,  relative  humidity  (0-100)  percent  (Default:  20.0) 

$W,  wind  speed  (Default:  3.0) 

$MMI,  maximum  allowable  metabolic  rate  -  initial  MOPP 
(Default:  1.E35) 

$MMA,  maximum  allowable  metabolic  rate  -  alternate  MOPP 
(Default:  1.E35) 

R,  (no  data  required)  Triggers  repeat  of  meteorological  conditions 
M,  metabolic  rate  (watts)  (Default:  250.0,  i.e.  light  exercise 
such  as  a  rifleman  on  patrol) 

This  is  followed  by  the  names  of  links  to  which  the 
rate  is  applicable: 

$link  name 
Slink  name 
Setc. 

C,  mopp  level,  clo  (clothing  parameter)  for  this  level 
(Defaults:  MOPPO  =  1.43;  MOPPl,  2,  and  3  =  2.07; 

MOPP4  =  2.32) 

I,  mopp  level,  im/clo  (clothing  parameter)  for  this  level 
(Defaults:  MOPPO  =  0.34;  MOPPl,  2,  and  3  =  0.22; 

MOPP4  =  0.15) 

GC,  gamma  (wind  correction  factor  for  clothing) 

(Default:  0.26) 


18.  R.E.  McNally,  M.M.  Stark,  and  D.T.  Ellzy,  Verification  and  Usage  of  the  Goldman-Givoni 
Model :  Predicting  Gore  Temperature  and  Casuaiiy  Generation  in  Thermaiiy  Sircssfui 
Environments,  Science  Applications  International  Corporation  under  contract  to  the  Medi¬ 
cal  Research  Development  Center,  Contract  No.  MDA903-88-D-1000,  (APR  1990), 
(UNCLASSIFIED). 
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GI,  gamma  (wind  correction  factor  for  im/clo) 

(Default:  0.38) 

S,  skin  temperature  (degrees  Celsius) 

(Default:  36.0) 

D,  percent  dehydration  (usually  0.0-7.0%) 

(Default:  0.0) 

A,  days  of  acclimatization  (Default:  12.0) 

NOTE  1: 

Having  determined  the  core  temperature  of  a  personnel  asset,  AURA 
compares  that  with  a  pre-selected  critical  temperature  (Tc)  for  that 
asset  group.  If  Tc  has  been  exceeded,  the  asset  at  th**  target  point 
(i.e.  doing  the  job  that  was  so  demanding)  becomes  • .  c:.  ialty.  The 
critical  temperature  is  drawn  from  a  cumulative  log  normal,  with  para¬ 
meters  mu  =  39.5  and  S.D.  =  0.5198.  AURA  uses  the  Goldman-Givoni 
model  *  for  calculation  of  HEAT  STRESS  effects. 

NOTE  2: 

Use  of  INTERNAL  RECONSTITUTION  TIMES  or  RECONSTITUTION 
EVENTS  resets  the  HEAT  STRESS  parameters  to  initial  values. 

3.  LINKS.  This  command  inputs  data  on  basic  subtasks  including: 

1.  relationships  between  number  of  effective  assets  allocated  to  an  individual 
task  and  effectiveness  of  task  performance; 

2.  limitations  on  numbers  of  entities  (i.e.,  actual  number  of  personnel  or 
items  of  equipment  assigned,  regardless  of  relative  worth  of  each  entity) 
which  may  be  assigned  to  task; 

3.  substitutes,  i.e.  assets  which  may  be  assigned  to  a  task  other  than  the 
task’s  HOMELINK  assets  (which  are  automatically  assignable)  (see 
HOMELINK,  p.  8). 

NOTE: 

All  LINKs  to  which  assets  may  be  assigned  must  be  deployed,  either 
through  being  a  HOMELINK  for  an  asset  that  is  deployed  or  by  be¬ 
ing  a  specifically  deployed  DUMMYLINK  (see  DUMMYLINK,  p.  7  and 
DEPLOYMENT,  p.  22).  However,  also  see  note  on  DUMMYLINKS, 
p.  46. 


19. Ibid. 
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Format: 


LINKS 

link  name,  caplOO,  maxeff,  entmax 
where: 

link  name  is  any  allowed  name  (see  p.  5).  If  link  name  is  also  the  name 
of  an  asset,  this  entry  defines  the  HOMELINK  for  that  asset. 

caplOO  is  number  of  effective  assets  needed  for  maximum  effectiveness 
(REAL) 

maxeff  is  maximum  effectiveness  in  percent  (REAL) 

Default:  maxeff  —  1.0 

entmax  is  maximum  number  of  items  that  may  be  assigned  to  LINK, 
entmax  is  taken  as  an  absolute  value  unless  an  ASSOCIA¬ 
TED  LINK  is  defined,  in  which  case  entmax  is  taken  as  the 
number  per  item  in  the  ASSOCIATED  LINK  (See  ASSOCI¬ 
ATED  LINK,  p.  48)  (REAL)  Default:  entmax  =  1.E35. 

NOTE  on  DUMMYLINKS: 

A  DUMMYLINK  without  substitutes  is  allowed.  (Such  a 
construct  can  be  used,  for  example,  to  provide  a  "sure 
path"  through  a  COMPOUND  LINK.)  Such  LINKs  need 
not  be  deployed. 


Option  1: 

Substitutes.  Substitutes  are  defined  by  sets  of  three  cards. 

Format: 

Ssubnml,  subnm2,  subnm3, .... 

$E,  effl,  eff2,  eff3,  .... 

$T,  timl,  tim2,  tim3,  .... 

where: 

subnml  is  the  name  of  the  Ith  substitute  (need  not  be  a  unique  name) 
effl  is  the  effectiveness  of  the  Ith  substitute  (relative  to  normal 
assets  implied  in  specifying  caplOO)  (REAL) 
timl  is  the  time  (intrvl)  needed  for  the  Ith  asset  to  substitute 
(REAL) 
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NOTE: 

It  is  essential  that  each  substitute  card  be  followed  by  an  effective¬ 
ness  card  and  a  time  card.  If  the  number  of  substitutes  exceeds 
the  capacity  of  the  first  substitute  card,  additional  substitutes  may 
be  specified  by  following  the  first  set  of  three  cards  with  other  sets. 

Option  2: 

Specify  lower  bounds  on  LINK  effectiveness. 

Format: 

$M,  capO,  mineff 
where: 

capO  is  number  of  effective  assets  below  which  effectiveness  is  minimum 
(REAL)  Default:  capO  =  0.0 
mineff  is  minimum  effectiveness  in  percent  (REAL) 

Default:  mineff  =  0.0 


Option  3: 

Specify  granularity  (maximum  amount  of  any  asset)  for  allocation 
into  LINK  in  any  one  installment.  Useful,  for  example,  to  cause 
allocation  scheme  to  consider  other  LINKs  before  totally  allocat¬ 
ing  any  asset  to  one  LINK. 

Format: 

$G,  grnlnk 

where: 

grnlnk  is  the  maximum  amount  to  be  allocated  in  any  one  pass 
(REAL).  Default:  grnlnk  =  0.5 

Option  4: 

Default  Granularity.  This  option  allows  changing  the  default 
value  for  the  LINK  granularity  (the  maximum  amount  will  be 
substituted  into  a  LINK  during  any  one  pass  of  the  allocation 
algorithm).  This  command  changes  the  granularity  for  all 
LINKs  which  do  not  have  a  granularity  specified  via  the  $G  op¬ 
tion,  no  matter  where  the  command  is  placed  in  the  runstream. 

Format: 

GRANULARITY,  new  default  (REAL) 
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Option  5: 

Specify  an  ASSOCIATED  LINK.  An  ASSOCIATED  LINK  is 
another  subtask  whose  potential  fulfillment  controls  the  enti¬ 
ties  assignable  to  the  current  subtask.  For  example,  if  there 
can  be  only  two  operators  per  system  X,  this  option  can  be  used 
as  follows:  System  X  would  be  defined  as  a  normal  LINK.  The 
operator  LINK  would  be  defined  with  2.0  for  the  value  of  entmax 
on  card  1  and  System  X  as  the  associated  LINK. 

Format: 

$A,  associated  LINK  name 

Option  6: 

Specify  an  effectiveness  level  below  which  a  substitution  will  not 
be  made.  This  takes  into  account  degradation  by  sublethal  doses, 
fatigue,  suboptimal  training,  and  MOPP. 

Format: 

$Q,  level  (Real)  Default:  level  =  0.1 

4.  SUBLETHAL  DOSE  DEGRADATION.  This  command  associates 
specified  LINKs  with  particular  dose-time  degradation  sets  which  can  be  used, 
e.g.,  to  degrade  dosed  individuals  assigned  to  physically  demanding  jobs  more 
severely  than  those  in  cognitive  jobs.  Two  degradation  sets  are  built  into  AURA 
which  describe:  a  gunner  (degradation  set  number  0),  typical  of  most  jobs  and  an 
ammunition  loader  (degradation  set  number  -1),  typical  of  a  physically  demand¬ 
ing  job.  The  default  for  all  LINKs  (without  use  of  this  command)  is  degradation 
set  0.  NOTE:  Degradation  code  number  -999  indicates  no  degradation. 

Format: 

SUBLETHAL  DOSE  DEGRADATION 

LINK  name,  code  number  (INTEGER) 

Option: 

Read  new  degradation  data  from  input  unit  #11.  This  option  also 
allows  reading  additional  degradation  sets  to  which  new  degrada¬ 
tion  set  numbers  (  1  -  5  )  are  given.  These  sets  are  then  available 
for  association  with  specific  LINKs. 
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NOTE: 

Format  for  the  degradation  data  in  unit  #  11  is  provided  in  Appendix  B 
in  Volume  2  of  the  AURA  Programmer/ Analyst  Guide/ 

Format: 

READ  11 

5.  TIME  DEPENDENT  (LINK)  DEGRADATION.  This  command  enables 
the  user  to  predefine  the  level  of  degradation  for  links  within  specific  time 
periods. 

Format: 

TIME-DEPENDENT  (LINK)  DEGRADATION 
TIME,  start  time  (REAL),  stop  time  of  period  (REAL) 

Slink  name,  degradation  factor  (REAL) 

Slink  name,  degradation  factor  (REAL) 

TIME,  start  time  (REAL),  stop  time  of  next  period  (REAL) 

$  .... 

Option  1: 

Degrades  all  links. 

Format: 

TIME,  start  time  (REAL),  stop  time  of  period  (REAL) 

$ALL,  degradation  factor  (REAL) 

TIME,  start  time  (REAL),  stop  time  of  next  period  (REAL) 

$  .... 


Option  2: 

Degrades  all  links  that  have  personnel  in  them. 
Format: 

TIME,  start  time  (REAL),  stop  time  of  period  (REAL) 
$ALL  PERSONNEL,  degradation  factor  (REAL) 

TIME,  start  time  (REAL),  stop  time  of  next  period  (REAL) 

$  .... 


20.  R.  Sheroke,  et  al,  Programmer /Analyst  Guide  for  the  Army  Unit  Resiliency  Analysis 
(AURA)  Computer  Simulation  Model,  Volume  2:  AURA  Source  Code,  USA  Ballistic 
Research  Laboratory,  BRL-TR-3103,  (JUL  90),  (UNCLASSIFIED). 
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Option  3: 

Repeat  above  sequence  every  1440  minutes  (24  hours). 

Format: 

REPEAT 
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F.  UNIT  FUNCTION  INPUTS 


The  following  data  sets  input  parameters  which  model  the  functional  struc¬ 
ture  of  a  unit  (see  FUNCTIONAL  STRUCTURE,  section  II.2  in  Volume  1  of  the 
AURA  Programmer/Analyst  Guide^1). 

1.  CHAINS.  This  command  allows  the  (overall)  concatenation  of  sets  of  opera¬ 
tions  (called  SEGMENTS)  to  satisfy  the  requirements  of  missions,  one  CHAIN  per 
mission.  Segments  may  be  any  previously  defined  LINKs,  CREWs,  SUBCHAINs, 
ORLINKs  or  COMPOUND  LINKs. 

Format: 

sgll,  sgl2,  sgl3,  sgl4 . .  sglJ 

sg21,  sg22,  sg23,  sg24,  ....,  sg2J 

sgll,  sgI2,  sgI3,  sgl4,  ....,  sglJ 

where: 

sglJ  is  the  Jth  segment  in  CHAIN  I. 

Option: 

A  continuation  line  which  begins  with  the  word  TIME  (may  be  abbrev¬ 
iated  to  T)  is  interpreted  as  a  set  of  (clock)  times  during  which  the  pre¬ 
ceding  CHAIN  is  operant.  Thus  enabling  the  available  missions  for  a 
unit  to  change  during  the  encounter. 

Format: 

$T,  strl,  stpl,  str2,  stp2,  ....,strl,  stpl 
where: 

strl  is  the  (clock)  time  that  a  CHAIN  becomes  operant  (REAL) 
stpl  is  the  corresponding  time  that  it  ceases  to  be  available  (REAL) 


21.  R.  Sheroke,  et  al,  Programmer/Analyst  Guide  for  the  Army  Unit  Resiliency  Analysis 
(AURA)  Computer  Simulation  Model,  Volume  1:  AURA  Methodology,  USA  Ballistic 
Research  Laboratory,  DRAFT  REPORT,  (AUG  90),  (UNCLASSIFIED). 
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2.  COMPOUND  LINKS.  This  command  inputs  data  for  COMPOUND  LINKs 
(CPLINKs),  i.e.  functional  structures  which  are  weighted  summations  of  tasks 
(called  cpparts).  A  cppart  may  be  a  simple  LINK,  a  CREW,  a  SUBCHAIN  or  an 
ORLINK.  NOTE:  A  COMPOUND  LINK  name  MUST  begin  with  the  !  charac¬ 
ter. 

Format: 

COMPOUND  LINK 

compound  link  namel  (must  begin  with  !) 
cppartll,  wtll 
cppartl2,  wtl2 

cppartlJ,  wtlJ 
compound  link  name2 
cppart2i,  wt21 

compound  link  namel 
cppartll,  wtll 
•  ••• 

cppartlJ,  wtlJ 
where: 

"compound  link  namel"  is  of  the  form  Ixxxxx  (e.g.  1LOADING  TECHNIQUE). 
cppartlJ  is  the  name  of  the  jth  part  of  CPLINK 

wtlJ  is  the  weight  of  cppart  IJ  (REAL) 

NOTE: 

The  weights  usually  sum  to  1.0  for  any  CPLINK.  A  warning  message 
is  printed  if  summation  is  not  1.0,  but  the  run  will  proceed. 

3.  CREW.  This  command  inputs  data  to  define  functional  structures  (called 
CREWs)  that  represent  sets  of  subtasks  that  must  work  together  to  accomplish 
part  of  a  mission.  The  relationship  between  tasks  in  a  CREW  are  generalized 
parallel  structures,  as  opposed  to  strict  ANDs  as  are  those  in  a  SUBCHAIN  (see 
SUBCHAIN  p.  55).  Individual  crew  jobs  must  be  LINKs.  Each  crew  position  has 
two  parameters,  alpha  (a)  and  beta  (0),  associated  with  it.  Table  2  contains  the 
general  crew  performance  formula  and  typical  values  of  alpha  and  beta  for  several 
3  and  4  member  crews.  In  addition,  each  crew  has  a  parameter  K. 

NOTE:  A  CREW  name  must  begin  with  the  =  character. 
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Table  2.  General  Crew  Performace  Formula: 


K 

Crew  Effectiveness  =  n 

(Si-)*1 

I 

i  =  1 

where:  n-  number  of  crew  members 

ej  -  effectiveness  of  the  i  th  crew  member 

and  K,  otj ,  and  P  j  are  constants,  (see  Table  2  below) 

Crew 

i 

K 

N 

a1 

D 

Q 

a4 

Pi 

P2 

P  3 

P  4 

M60A3 

TANK 

1-  tank  cmdr 

2-  gunner 

3-  loader 

4-  driver 

0.85511 

020698 

0.19297 

0.28214 

026697 

0.98866 

1.1181 

1.2815 

1.0046 

IMPROVED 

TOW 

VEHICLE 

1-  Sqd  leader 

2-  gunner 

3-  loader 

4-  driver 

121568 

0.15823 

057907 

026296 

021568 

1.0389 

1.0137 

0.96201 

1.0000 

Ml  09  GUN 

1-  gunner 

2-  asst,  gunner 

3-  chief  of  sect 

4-  loader 

0.87112 

1 

0.06623 

0.06042 

021749 

052720 

12502 

0.67995 

1.0037 

1.1755 

FIRE 

DIRECTION 

CENTER 

1-  Fire  direct, 
officer 

2-  computer 

3-  horizontal 
control 
officer 

0.96320 

3 

0.22923 

035553 

0.43305 

— 

1.6017 

0.81154 

0.98212 

— 
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Format: 


CREW 

crew  namel  (must  begin  with  =) 
Nl,  K1 

LINKl,  alphal,  betal 
LINK2,  alpha2,  beta2 
crew  name2 
N2,K2 


where: 

"crew  name"  is  of  the  form  =xxxxx  (i.e.  =GUN  CREW). 

Nj  is  the  number  of  members  in  the  jth  crew  (INTEGER) 

Kj  is  the  crew  parameter  for  the  jth  crew  (REAL) 

lnkl  is  the  name  of  the  Ith  LINK  in  the  crew 

"alpl  and  betl"  are  the  parameters  for  the  Ith  task  in  the  crew  (REAL) 
e,-  is  calculated  by  AURA  based  upon  the  decisions  of 

the  commander  model. 

4.  ORLINKS.  This  command  inputs  data  to  define  functional  structures  (called 
ORLINKs)  that  represent  mutually  exclusive  choices  for  the  accomplishment  of 
part  of  a  mission.  The  choices,  called  "branches",  may  be  SUBCHAINs,  CREWs 
or  simple  LINKs.  NOTE:  An  ORLINK  name  must  begin  with  the  +  character. 

Format: 

ORLINKS 

orlink  name,  brl,  br2,  br3,  ....brl  (name  must  begin  with  +) 
where: 

orlink  name  is  of  the  form  +xxxx  (i.e.  ^-Communication), 

brl,  the  Ith  branch,  is  the  name  of  a  LINK,  CREW  or  SUBCHAIN 
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5.  SUBCHAINS.  This  command  inputs  data  to  define  functional  structures 
(called  SUBCHAINs)  that  represent  sets  of  subtasks  that  must  work  together  to 
accomplish  part  of  a  mission.  The  relationship  between  elements  in  a  SUBCHAIN 
are  simple  ANDs:  the  value  of  a  SUBCHAIN  equals  the  value  of  its  weakest 
member.  The  elements  of  a  SUBCHAIN  may  be  CREWs  and/or  simple  LINKs. 
NOTE:  A  SUBCHAIN  name  must  begin  with  the  *  character. 

Format: 

SUBCHAINS 

subchain  name,  lnkl,  lnk2,  lnk3,  ....  (name  must  begin  with  *) 

where: 

"subchain  name"  is  of  the  form  *xxxx  (e.g.  *FORKLIFT  TEAM) 
lnkl  is  the  name  of  the  Ith  LINK  or  CREW  in  the 

SUBCHAIN 
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G.  PROGRAM  CONTROLS 


The  following  input  parameters  control  the  running  of  the  code,  the  decision 
logic  used,  the  outputs  produced  and  scenario  parameters  such  as  the  length  of 
(clock)  time  of  the  encounter. 

1.  DECISION  RULES.  This  command  allows  resetting  certain  default  condi¬ 
tions  and  values  that  control  the  rules  by  which  the  allocation  algorithm  chooses 
assets  for  assignment  into  the  various  LINKs.  The  allocation  algorithm  (com¬ 
mander)  normally  considers  versatility  of  the  asset  before  considering  the  order  of 
user  listed  assets  on  a  substitution  card  (see  LINKS,  p.  45).  In  AURA,  versatility 
is  the  ability  of  an  asset  to  perform  more  than  one  job.  This  command  allows 
choosing  whether  versatility  or  user-input-order  is  to  be  the  fir^t  consideration 
(see  ALLOCATION  DECISION  RULES,  Volume  I  section  IV.l.b). 

Format: 

DECISION  RULES 

PRIORITY,  first  consideration 

where: 

first  consideration  is  VERSATILITY  (default)  or  ORDER 

Option  1: 

Significance.  This  option  allows  specifying  the  fractional  improvement 
needed  before  the  allocation  algorithm  will  ignore  differences  in  order 
and  versatility  (for  example,  signif  =  0.5  means  that  an  asset  having 
1.5  times  the  effectiveness  of  the  current  best  choice  will  automatically 
become  current-best-choice,  regardless  of  versatility  or  order). 

Format: 

SIGNIFICANCE,  signif 

where: 

signif  is  the  required  improvement  (REAL).  Default:  signif  =  0.005 


22.  Ibid, 


56 


Option  2: 

Sickness  level.  This  option  allows  specifying  the  degraded  level  of 
performance  (for  example,  due  to  sickness  or  fatigue)  that  an  as¬ 
set  must  show  in  order  to  be  preempted  in  its  HOMELINK  by  a  sub¬ 
stitute  (for  example,  sicklv  =  0.75  means  that  if  a  HOMELINK  as¬ 
set  were  at  effectiveness  0.5  and  a  substitute  were  available  at  eff¬ 
ectiveness  greater  than  0.67  (  =  0.5  /  0.75  ),  then  the  HOMELINK 
asset  would  be  replaced  in  his  job). 

Format: 

SICKLV,  sicklv 

where: 

sicklv  is  the  required  degradation  (REAL).  Default:  sicklv  =  0.75 
Option  2: 

Finish  repair.  This  option  allows  specifying  the  relative  worth  in  fin¬ 
ishing  an  ongoing  NEEDED  repair  rather  than  starting  another  NEED¬ 
ED  repair.  For  example,  fnshrp  =  2.0  means  that,  if  an  ongoing  repair 
has  0.6  of  an  item  left  to  fix,  the  code  will  calculate  the  anticipated 
gain  based  upon  receiving  1.2  (  =  2.0  *  0.6)  items.  This  would  be 
compared  to  the  anticipated  gain  from  any  other  repair  which  might  be 
initiated  in  order  to  solve  a  mission  limitation.  The  repair  which  prom¬ 
ises  the  most  gain  is  the  one  selected  by  the  optimization  algorithm  to 
add  to  the  mission  requirements  to  calculate  the  mission  cost  of  (NEED¬ 
ED)  repair.  Note  that  this  parameter  only  influences  NEEDED  repairs, 
as  defined  on  p.  18. 

Format: 

FINISH  REPAIR,  fnshrp 
where: 

fnshrp  is  the  relative  gain  (REAL).  Default:  fnshrp  =  2.0 

2.  GO.  This  command  indicates  that  all  data  has  been  entered  and  the  simula¬ 
tion  and  analysis  should  begin. 

Format: 

GO 
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3.  HEADING.  This  command  allows  the  user  to  write  a  message  at  the  begin¬ 
ning  of  the  AURA  output  and  again  at  the  beginning  of  the  results.  This  message 
is  in  addition  to  any  message  entered  via  the  computer  normal  input  channel  dur¬ 
ing  execution. 

Format: 

HEADING 

message 

4.  INTERNAL  RECONSTITUTION  TIMES.  This  command  inputs  a 
matrix  of  times  (intervals)  following  a  lethality  or  reconstitution  ev  it  at  which 
outputs  are  desired.  Every  lethality  event  (see  ROUND,  p.  34  and  VOLLEY,  p. 
35)  and  reconstitution  event  (see  RECONSTITUTION  EVENTS,  p.  67)  cause  the 
internal  clock  to  reset.  Then,  at  the  end  of  interval  1,  interval  2,  etc.,  the  code 
updates  all  time  dependent  factors,  reallocates  assets  and  compiles  all  statistics  to 
be  used  in  the  final  results.  In  this  way,  the  user  establishes  the  time  points  at 
which  results  will  be  reported. 

Format: 

INTERNAL  RECONSTITUTION  TIMES 

tml,  tm2,  tm3,....  (maximum,  47  times) 

where: 

tml  is  the  Ith  time  point  (intrvl)  after  a  lethality  event  (REAL) 

5.  MODE.  This  command  controls  certain  choices  in  operation  of  the  code. 
Option  1: 

CODE  mode.  Used  in  code  development  to  track  internal  parameters. 
Format: 

MODE 

CODE,  ON  or  OFF  (Default:  OFF) 

Option  2: 

CULL  mode.  In  CUL-,  .node,  incoming  rounds  are  screened  (in  the 
ROUND  and  VOLLEY  input  routines)  to  predetermine  if  the  round 
has  a  potential  of  affecting  a  target  point.  This  allows  using  one, 
standard,  large,  scenario-wide  threat  in  the  runstreams  for  all  tar¬ 
gets  in  the  scenario:  AURA  will  assess  only  those  weapon  employ¬ 
ments  which  might  affect  the  unit  being  studied  in  each  runstream. 
Those  weapons  "culled  out"  are  those  which  are  outside  the  range. 


NOTE: 

If  running  in  CULL  mode,  weapon  employment  data  (ROUND  or 
VOLLEY)  must  be  preceded  by  weapon  characteristic  data  (DEP¬ 
LOY,  DELIVERY,  TLE,  NUCLEAR,  CONVENTIONAL,  or  TO¬ 
XIC.) 

Format: 

CULL,  ON  or  OFF  (Default:  OFF) 

Option  3: 

DEBUG  mode.  Causes  the  code  to  process  input  data  but  not 
execute.  Used  to  debug  runstreams. 

Format: 

DEBUG,  ON  or  OFF  (Default:  OFF) 

Option  4: 

PRIORITY  mode.  Changes  the  interpretation  of  COMPOUND  LINKs. 
In  PRIORITY  mode,  parts  of  COMPOUND  LINKs  (cpparts)  are  consid¬ 
ered  in  order  of  entry  AND  failure  to  improve  one  cppart  stops  the  opt¬ 
imization  process.  The  following  restrictions  apply: 

a.  unit  structure  consists  of  a  single  COMPOUND  LINK  whose 
cpparts  are  all  simple  SUBCHAINs; 

b.  every  LINK  is  modeled  as  a  0.  -  1.  step  function  (i.e.  a  job 
is  either  at  0%  or  else  100%); 

c.  all  substitutes  are  100%  capable; 

d.  degradation  of  assets  is  not  played; 

e.  only  one  asset  may  be  assigted  per  job. 


Format: 


PRIORITY,  ON  or  OFF  (Default:  OFF) 


Option  5: 

INDIVIDUAL  DOSES.  Causes  AURA  to  separate  all  asset  groups 
into  individuals  and  give  each  one  its  unique  sensitivity  to  doses 
and  heat  stress. 


INDIVIDUAL  DOSES,  ON  or  OFF  (Default:  ON) 
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Option  6: 

STOCHASTIC  mode.  Causes  all  lethality  assessments  to  be  stoch¬ 
astically  determined.  In  STOCHASTIC  mode,  the  AURA  lethality 
routines  draw  random  numbers  against  calculated  probabilities  to 
determine  damage  or  kill.  (In  normal  mode,  fractional  kills  are 
tallied.) 

Format: 

STOCHASTIC,  ON  or  OFF  (Default:  OFF) 

Option  7: 

TIME  BEFORE  ZERO.  This  option  allows  resetting  the  assumed  time 
that  has  elapsed  before  start  of  analysis,  ius  limiting  the  substitutions 
that  can  be  assumed  for  the  time  =  0.0  reconstitution.  The  infinite  de¬ 
fault  time  allows  all  needed  substitutions  to  be  made  before  commence¬ 
ment  of  analysis. 

Format: 

TIME  BEFORE  ZERO,  time  (intrvl)  (REAL) 

6.  OUTPUT.  This  command  controls  the  printing  of  optional  outputs  from  an 
AURA  run.  The  definition,  interpretation  and  use  of  these  outputs  will  be  the 
subject  of  Volume  3  of  the  AURA  Programmer/ Analyst  Ouide.  The  results  are 
averaged  over  all  replications  for  every  output  command. 

Option  1: 

BINS.  Reports  the  contents  of  all  radiation  accumulation  bins 
for  every  asset  at  reporting  times  that  fall  within  the  specified 
intervals. 


Format: 

BINS,  strtl,  stpl,  strt2,  stp2,  ....  (Default:  OFF) 
where: 

strtl  is  the  start  time  (clock)  for  the  Ith  interval  (REAL) 
stpl  is  the  ending  time  (clock)  for  the  Ith  interval  (REAL) 
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Option  2: 

CASUALTIES.  Reports  all  casualties,  contaminations,  ETI  episodes 
and  expenditures  as  they  occur.  If  WEAPON  report  is  not  ON,  this 
option  also  describes  incoming  warheads  which  cause  immediate  cas¬ 
ualties  (see  PARTICULAR  ASSETS  option,  p.  64). 


Format: 

CASUALTIES,  ON  or  OFF  (Default:  OFF) 

Option  3: 

CHAIN.  Prints  line-printer  depiction  of  unit  functional  structure. 


Format: 

CHAIN,  ON  or  OFF  (Default:  ON) 

Option  4: 

DEPDMP.  Reports  the  precise  deployment  of  all  assets  at  reporting 
times  that  '  "  within  the  specified  intervals. 


Format: 

DEPDMP,  strtl,  stpl,  strt2,  stp2,  ....  (Default:  OFF) 
where: 

strtl  is  the  start  time  (clock)  for  the  Ith  interval  (REAL) 
stpl  is  the  ending  time  (clock)  for  the  Ith  interval  (REAL) 

Option  5: 

DEPLOYMENT  PLOT.  Prints  line-printer  depiction  of  unit  deploy¬ 
ment,  including  initial  wind  and  incoming  fire  directions  (see  SELEC¬ 
TIVE  PLOT  option,  p.  66). 


Format: 

DEPLOYMENT  PLOT,  ON  or  OFF  (Default:  ON) 

Option  6: 

DOSE.  Reports  all  nuclear  or  toxic  doses  as  received  (cumulated  to  the 
nearest  reporting  time)  (see  PARTICULAR  ASSETS  option,  p.  64) 


Format: 

DOSE,  ON  or  OFF  (Default:  OFF) 
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Option  7: 

DUMP8.  Causes  reallocation  information  (time,  effectiveness,  weak 
LINKs,  strongest  CHAIN)  to  be  written  onto  output  unit  #8  at  every 
reporting  time. 


Format: 

DUMP8,  ON  or  OFF  (Default:  OFF) 

Option  8: 

DUMP9.  Causes  incoming  weapon  information,  including  actual  burst 
points  for  every  warhead  in  every  replication  to  be  written  onto  output 
unit  #9.  This  information  is  used  by  the  BRL  graphical  post-analysis 
utility  programs  to  aid  in  analysis  of  results. 


Format: 

DUMP9,  ON  or  OFF  (Default:  OFF) 

Option  9: 

ETIPCI.  If  ON,  causes  at-end  average  of  nuclear  dose  effects  (aver¬ 
age  performance  degradations,  Early  Transient  Incapacitation  epis¬ 
odes  and  Permanent  Incapacitation  occurrences)  to  be  printed.  If 
FULL,  also  causes  intermediate  information  to  be  written  onto  out¬ 
put  unit  #10. 


Format: 

ETIPCI,  ON  or  FULL  or  OFF  (Default:  ON) 

Option  10: 

FATIGUE.  If  RECONSTITUTION  (see  p.  65)  is  ON  or  PARTIAL, 
this  option  prints  out  the  fatigue  status  of  all  assets. 

Format: 

FATIGUE,  ON  or  OFF  (Default:  OFF) 
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Option  11: 

INPUT  LISTING.  Causes  the  code-interpreted  input  data  to  be 
printed  at  beginning  of  output. 


Format: 

INPUT  LISTING,  wordl,  word2,  word3, ...  (Default:  OFF) 
where: 

word  = 

ON 
OFF 

EVENTS 
WEAPON 
ASSETS 
NUCLEAR 
TOXIC 
REPAIR 
LINKS 

FUNCTIONAL 
DEPLOYMENT 

Option  12: 

LETHALITY.  Causes  input  units  #2,  #3  and/or  #4  (conventional 
lethality  file,  nuclear  vulnerability  file  and  toxic  dispersion  file, 
respectively),  if  used,  to  be  rewound  and  copied  onto  the  end  of  the 
AURA  output. 


to  turn  on  full  beginning  output  (Default:  ON) 

to  turn  off  all  beginning  output 

to  print  event  table 

to  print  weapon  identification  table 

to  print  asset  identification  table 

to  print  nuclear-related  parameters 

to  print  toxic-related  parameters 

to  print  failure  and  repair  parameters 

to  print  LINK  definition  table 

to  print  substitution,  SUBCHAIN,  ORLINK  and 

COMPOUND  LINK  status  tables 

to  print  deployment  table 


Format: 


LETHALITY,  ON  or  OFF  (Default:  ON) 

Option  13: 

NUCLEAR  SUMMARY.  Causes  an  at-end  report  detailing  nuclear 
casualties  from  blast  or  thermal  dosages. 


Format: 

NUCLEAR  SUMMARY,  ON  or  OFF  (Default:  OFF) 
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Option  14: 

OPTIMIZE.  Causes  a  highly  detailed  report  of  every  step  attempted 
in  every  optimal  reallocation  process  which  occurs  during  the  specif¬ 
ied  time  intervals. 


Format: 

OPTIMIZE,  strl,  stpl,  str2,  stp2,  ...,  iunwlk  (Default:  OFF) 
where: 

strl  is  the  start  time  (clock)  for  the  Ith  interval  (REAL) 
stpl  is  the  ending  time  (clock)  for  the  Ith  interval  (REAL) 
iunwlk  is  an  optional  flag  to  redirect  this  output  (INTEGER) 
iunwlk  >  0  «  output  on  printer 
iunwlk  <  0  =  output  written  to  unit  #13 
Default:  iunwlk  =  1  no  optimization  steps  reported 


Option  15: 

PARTICULAR  ASSETS.  Restricts  the  assets  to  be  included  in 
casualty  reports,  dosages,  contamination  reports,  etc. 


Format: 

PARTICULAR  ASSETS,  asset  namel,  asset  name2, ...  (Default:  OFF) 

NOTE: 

Common  asset  names  can  be  used;  any  number  of  assets  can  be  included. 
Option  16: 

POSTURE.  Causes  a  report  of  all  posture  changes.  If  ON,  every 
individual  is  reported;  if  PARTIAL,  group  changes  are  reported 
(see  PARTICULAR  ASSETS  option  above). 


Format: 

POSTURE,  ON  or  PARTIAL  or  OFF.  (Default:  OFF) 

Option  17: 

PRINT7.  Causes  all  output  to  be  sent  to  output  unit  #7. 
(Default:  AURA  output  unit  #6) 

Formal: 

PRINT7,  ON  or  OFF.  (Default:  OFF) 
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Option  18: 

RANDOM  NUMBER.  Causes  report  of  the  random  nu^er  seeds  at 
the  beginning  of  each  replication. 


Format: 

RANDOM  NUMBER,  ON  or  OFF  (Default:  ON) 

Option  19: 

RECONSTITUTION.  Causes  output  after  every  reconstitution.  If 
ON,  a  complete  matrix  of  assets  assigned  versus  LINKs  is  produced. 
If  PARTIAL,  only  a  summary  of  results  with  a  report  of  assignments 
into  the  weak  LINK  is  given.  If  ONCE,  a  complete  matrix  of  asset 
assignments  is  given  for  the  initial  arrangement  only.  If  time  inter¬ 
vals  are  specified,  a  complete  matrix  of  asset  assignments  is  reported 
for  any  reconstitution  which  occurs  during  the  specified  intervals. 


Format: 

RECONSTITUTION,  ON  or  PARTIAL  or  ONCE  or  OFF.  (Default:  OFF) 

RECONSTITUTION,  strl,  stpl,  str2,  stp2, ... 

where: 

strl  is  the  start  time  (clock)  for  the  Ith  interval  (REAL) 
stpl  is  the  ending  time  (clock)  for  the  Ith  interval  (REAL) 

Option  20: 

REPAIR  REPORT.  If  ON,  causes  a  report  of  all  repair  activities 
at  each  reporting  time.  If  FULL,  also  gives  a  complete  status  of 
damaged  items  available  for  repair  at  each  time. 


Format: 

REPAIR  REPORT,  FULL  or  ON  or  OFF.  (Default:  OFF) 

Option  21: 

REPLICATION.  Causes  table  of  survivors  versus  time  to  be  reported 
at  the  end  of  every  replication. 


Format: 

REPLICATION,  ON  or  OFF  (Default:  OFF) 
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Option  22: 

SELECTIVE  PLOT.  Restricts  the  assets  depicted  in  the  lineprinter 
deployment  plot  (see  DEPLOYMENT  PLOT  option,  p.  61). 


Format: 

SELECTIVE  PLOT,  asset  namel,  asset  name2,  ...  (Default:  ON) 

NOTE: 

Common  asset  names  can  be  used;  any  number  of  assets  can  be  included. 
Default:  all  assets  included. 

Option  23: 

SUMMARY.  Gives  an  at-end  sum  of  survivors  versus  time,  with  stan¬ 
dard  deviations  of  the  averages  over  replications.  This  output  elimin¬ 
ates  the  need  to  add  up  the  final  output  results  for  several  assets.  The 
user  need  only  give  the  assets  a  common  name  (see  NAMES,  p.  13) 
and  request  a  summary  on  the  common  name  via  this  option.  Com¬ 
monly  used  to  summarize  total  casualties  for  PERSONNEL. 


Format: 

SUMMARY,  common  namel,  common  name2,  ...  (maximum,  6) 
SUMMARY,  OFF  (Default:  OFF) 

Option  24: 

TIMER.  Allows  user  to  measure  the  computer  time  used  by  various 
portions  of  an  AURA  run. 


Format: 


TIMER,  opt  (Default:  OFF) 
where  opt  is: 


ON: 

OFF: 

INPUT: 

OPTIMIZATION: 

RECONSTITUTION: 


times  major  segments 
no  timing 

times  the  input  and  preprocessor  algorithms 

times  the  various  algorithms  in  the  optimal  allocation 

process 

times  over-all  reconstitution  process  (  updating,  inven¬ 
tory,  optimization,  etc.  ) 
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Option  25: 

WEAPON.  Causes  a  report  of  every  weapon  arrival  (type,  time,  aim 
point,  burst  point). 


Format: 

WEAPON,  ON  or  OFF  (Default:  OFF) 

7.  RECONSTITUTION  EVENTS.  This  command  causes  a  reset  of  the 
internal  time  clock  to  restart  a  series  of  output  time  points.  It  also  resets  HEAT 
STRESS  parameters  (see  INTERNAL  RECONSTITUTION  TIMES,  p.  58). 

Format: 

RECONSTITUTION  EVENTS 
timel,  time2, ... 

where: 

timel  is  the  Ith  (clock)  time  from  which  a  series  of  reporting  times  will  be 
generated  (REAL) 

8.  REPLICATIONS.  This  command  specifies  the  number  of  replications  to  be 
performed. 

Format: 

REPLICATIONS 

number  of  replications  (INTEGER) 

9.  SEEDS  (Random  Number).  This  command  allows  presetting  the  random 
number  seeds  before  beginning  a  run.  This  command  is  particularly  useful  if  one 
wishes  to  repeat  one  particular  replication  of  a  previous  run,  perhaps  with  special 
output  options.  Note  that  there  are  a  number  of  random  number  sequences,  each 
with  its  own  seed,  maintained  in  AURA. 

Format: 

SEEDS  (RANDOM  NUMBER) 
sdnm,  seedvalue 
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where  sdnm  is: 

WEAPON,  to  set  seed  number  (sdnm)  1  which  primarily  effects  weapon 
delivery  processes 

OTHER,  to  set  seed  number  (sdnm)  2  which  effects  processes  not  specifi¬ 
cally  seeded 

FAILURE,  to  set  seed  number  (sdnm)  3  which  effects  random  failures 
STOCHASTIC,  to  set  seed  number  (sdnm)  4  which  is  used  to  select  kills 
in  stochastic  mode  (see  MODE,  p.  58). 

HEAT  CASUALTIES,  to  set  seed  number  (sdnm)  5  which  selects  heat 
stress  casualties 

seedvalue  is  the  desired  seed  (REAL) 

10.  STOP.  This  command  indicates  the  end  of  the  runstream  file.  The  STOP 
command  must  be  the  last  card  of  the  input  runstream. 

Format: 

STOP 

11.  TRACE  LINK  USAGE.  This  command  causes  reporting  of  specified 
LINKs  being  used  or  specified  LINKs  being  weak.  Useful  as  an  aid  to  tracking 
down  erratic  or  inexplicable  LINK  behavior. 

Format: 

TRACE 

WEAK  LINK,  link  name,  rec 
or 

USES,  link  name,  rec 
where: 

"link  name"  is  the  name  of  the  link  being  traced 
rec  is  the  reconstitution  number  of  interest  (i.e.  the  recon¬ 

stitution  in  which  a  use  or  weak  LINK  occurrence  of 
the  specified  LINK  is  to  be  reported)  (INTEGER) 
or 

rec  can  be  the  word  ANY  to  report  all  such  occurrences. 
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V.  Current  BRL  Efforts  in  AURA  Development 


Current  work  on  AURA  includes  the  development  of  methodologies  such  as: 

-  Evaluation  of  capability/effectiveness  of  ’smart’  munition  weapons  systems; 

-  Aiming  methodologies  for  indirect  fire  weapon  systems  (FENDERKOV 

and  the  Battery  Computer  System  (BCS)  methodology); 

-  A  more  precise  modeling  of  multiple  agent  chemical  attacks. 

In  addition,  work  is  being  directed  toward  the  automation  of  the  AURA 
analysis  process.  The  goal  of  the  automation  process  is  to  make  it  feasible  for 
one-sided  unit  level  analysis  to  be  made  quickly,  easily,  and  uniformly  throughout 
the  diverse  Army  analysis  community,  using  the  most  current  data  and  algo¬ 
rithms  available  from  the  various  proponent  agencies. 
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VI.  SUMMARY 


This  manual  has  presented  the  current  repertoire  of  commands  for  the 
Army  Unit  Resiliency  Analysis  (AURA)  computer  code.  It  is  clear  from  the 
number  and  diversity  of  commands  that  the  methodology  is  extremely  flexible, 
with  algorithms  designed  to  model,  in-depth,  a  large,  broad,  detailed  spectrum  of 
battlefield  factors. 

This  manual  has  been  organized  to  provide  the  user  with  the  necessary  com¬ 
mand  formats,  parameters,  and  default  values  which  may  be  used  in  the  AURA 
model.  Appendix  A  provides  example  input  runstreams  for  a  Nuclear,  Chemical, 
and  Conventional  scenario.  Appendix  C  provides  a  complete  index  of  all  AURA 
commands. 

Not  covered  in  this  report  is  the  method  by  which  the  user  may  vary  the 
AURA  inputs  to  model  the  various  battlefield  phenomena  (such  as  combined 
weapon  attacks).  Volume  3  of  the  AURA  Programmer/Analyst  Guide  will 
address  these  issues  by  providing  a  guide  to  conduct  an  AURA  analysis  -  from 
data  preparation  through  analysis  of  outputs  and  investigation  of  results  -  from 
an  analyst’s  perspective. 
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APPENDIX  A 


AURA  Input  Runstreams  for  Nuclear,  Chemical  and  Conventional  Scenarios 
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The  appt.  ”x  is  provided  to  illustrate  and  clarify  ihe  organization  and  for¬ 
mat  of  AURA  input  runstreams.  Contained  within  the  appendix  are  examples  of 
input  runstreams  representing  the  hypothetical  mission  of  an  Ammunition  Supply 
Point  (ASP)  unit  in  a  nuclear,  conventional,  and  chemical  scenario. 
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#TH1S  ts  AN  EXAMPLE  CF  AN  AURA  INPUT  RUNBTREAM  POR  UMTT  MISSION  IN' A  ,  UCLEAR 
#SCENARIO. 

#ALL  LINES  FRECEEDED  BY  A  #  SIGM  ARE  CONLCNTS  TO  FACO-fTATE  THE  UNDERSTANDING 
#OF  THE  1NEVT  CONMANC6. 

REPERTOIRE  #OR  'NANC?  OOULD  BE  USED 
WEAPON: 

# 

#THE  MJCLEAR  WEAPON  USED  IS  NAMED  KT30 

# 

Krao,MJCLEAR  #OR  NUKE  CAN  EE  USED  FOR  NUCLEAR 
PCS 
# 

#THE  PERSONNEL  AND  EQUIPNENT  REQUIRED  POR  A  MISSION; 

# 

FIREMENtPERSONNEL 

FIRETEAM.PERSONNEL 

cram; 

FRKLPTOA,PORKUm, FORKLIFT 
PRKLmsBlPORKUFW.PORKLIFT 


TRACTOR10.TRUCK5T 
'VR£CKER,TRUCK6T 
S STACKS 
PROP  STACKS 


CRANE  OPER.PERSONNEL 
UFT/LOAD  OP, PERSONNEL 
DUKMYMAINT, PERSONNEL 
EXJKMY  SERVO,  PERSONNEL 
END 

DEFLOYVENT 

# 

#THE  DEPLOYMENT  PARAMETERS  OF  THE  ASSETS. 

# 

CRANE;  511  00,  1420100,1.,  1,  1,  1,  1,  1,  0 

# 

#ONE  WAY  TO  CHANGE  POSTURES  POR  THE  CONVENTIONAL,  NUCLEAR.  AND  CHEMICAL 
#SC£NARJ06  AT  A  SPECIFIED  TINE 
# 

12.1. . 6.4. .6 

CRANE;  1350.00,  1738.50,1.,  1,  1,  1,  1,  1,  0 

12.1. . 6. 4,-6 


PROP  STACKS,  1322.08,  1076.00,1.,  1,  1,  1,  1,  1,0 
12,1,  .5,4.  5 

B  STACKS  ,  1406.80,  1001.40,1.,  1,  1,  1,  1,  1,0 
J2,1,A4,.6 


TELEPHONE,  1088  14,  1800.15,1.,  1,  1,  1,  1,  1,0 

12.1. . 6. 4,-6 

TRUCK,  1087.24,  I860  02,1.,  1,  1,  1,  1,  1,  0 

12.1. . 6.4,  5 


FIREMEN  ,  1661.43, 1073.04,  -1.,  1,1,1,  1, 1,  0 

12.1. . 6. 4,-6 

FIRETEAM1651.4C,lcr7ae4,-20.,l,l,l,l,  1,  0 

12.1. . 6. 4,-5 
END 

NUCLEAR  VULNERABtLTTY  DATA 

# 

#AURA  READS  A  NDCLEAR  VULNERABILITY  FILE  VIA  INPl/T  UNIT  NUKEER  a 

# 

END 

DELIVEFY  ERRORS 

# 

#DEFI NE THE  DELIVERY  ERRORS  CF  WEAPON  KI30 

# 

KT30,ia,14a,0  ,46,0. 

END 
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YIELD 

# 

♦DEFINE  THE  YIELD  OF  WEAPON  KT30, 

# 

Krao,ioa 

EH) 

DCSE  PARAMETERS 

# 

# DEFINE  PARAVETERS  WHICH  CONTROL  THE  PERSONNEL  RESPONSE.TO-D06ACE  ALGORITHMS 
#AND  THE  OUTPUT  RETORT  OF  DOSAGES. 

# 

DC6E  BINS, 5, 77., 145, 300., 4#)., 540  ,840.,1100.,148U  ,4000. 

# 

#SET  MAXIMUM  DOSAGE  TO  EE  CONSIDERED  AN  INSTANT  CASUALTY. 

# 

max  dose;  oooo. 

ETC 

THERMAL 

# 

♦SPECIFY  THE TYPE  OF  UNIFORM  EEI NG  WORN 

# 

UMTORM.SUVMER 

EH) 

SHIELDING 

♦ 

♦DEFINE  THE  NUCLEAR  POSTURE  COOE  NULCERS. 

# 

TRACTOR10,4,0.7,O.0,a0,0.4 

WRECHER,6,.g,ao,aO,a6 


TRAILER  1 2,0, 1 .0,0. 0,0.0, 1 .0 
END 
ROUND 
# 

♦INPUT  THE  PARAMETERS  NECESSARY  TO  SPECIFY  AN  ATTACK  BY  A  S1NCLE  ROUND 
♦PER  ADvFOU-.T  CHOSEN  API  ERRORS  ARE  DRAWN  ONCE  FOR  EACH  LINE  OF 
♦INPUT  FOR  BOTH  THE  ROUND  AND  THE  VOLLEY  COMMANDS.  PRECISION  OR  ROUND 
♦TO  ROUND  ERRORS  ARE  DRAWN  FOR  EACH  INCOMING  ROUND 
# 

Kreo,a,«7.,is22.,ao 

KT»,a,2016.,1722.,aO 

kt  j,a,i53a,707„ao 

END 

LNKS 

i 

# THE  UNK  ORGANIZATION  FOR  A  DEFINED  MISSION. 

♦ 

FIREXCH.5 
I  PERSONNEL 
ST,1. 

Sell 

FTRCTEAM,*. 

SPERSONNEL 

ST,1. 

S&1. 


REX)ORD  CLERK.8.,8. 

SM.2.,25 

SCOMdO  OFERS,TYPtST,RTFL  CHIEF, OFERATOR,CRANE  OPER.CRANE  CHER 
ST, 120., 140., 7a, 40., 40, 30. 

SE.0,.7,1.,1.,1.,1. 

^CHECKERS 

ST.8. 

SE.L 


OPERATOR  M.4.,4. 

jNOaOCAtAD  OPERS,  RECORD  CLERK.MAINT  STAFF,  REOOV  OPER^ERVC  PERS 

ST, iso., iso., sa, «o., 7a, «a 

Se;.8,ai.,i.,i.,i. 

Suft/lqad  op, crane  ofer 

ST, 45., 25. 

SE.1.,1. 
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ASTACKS.8. 

B  STACKS,#. 

FROPSTACKS-8. 

C  STACKS,*. 

DSTACKS,588 
E  STACKS,  M- 
F  STACKS,  588 
END 

SUBCHAINS 

# 

#DEFINE  FUNCTIONAL  STRUCTURES  THAT  REPRESENT  SETS  OF  SUETASKS. 

# 

*l,FRKLFTeA,OPERATOR  A 
^FRKLFTSB,OPERATOR  B 
•S.FRKLFTBQOPERATOR  C 


•I4.MA1NT  LOLAUTO  TEK>l,TRACrOR£,TRAILER12,TRACTORlO,TRAILEP25 
•16,DUNf4Y  MAINT,DU\MY  SERVO 
*18, B  STACKS,  FROP  STACKS 
EM) 

ORUNKS 

# 

#  DEFINE  FUNCTIONAL  STRUCTURES  THAT  REPRESENT  KWTUALLY  EXCLUSIVE  CHOICE  FOR 
#THE  AOCONFLISHMENr  OF  PART  OF  A  MISSION 

# 

+l,*l,USERSA 
+2,*2,U5ERSB 
+S,*S,USERS  C 


+11, *11, USERS  M 
END 

CONFOUND  LINKS 

# 

#D£FINE  FUNCTIONAL  STRUCTURES  WHICH  ARE  WEIGHTED  SUK*4ATIONS  OF  PARTS. 

# 

JINHE 


+1..083 

+2,-083 

+3,-083 


D  STACK5./M 

ESTACKS-,07 

F  STACKS,. 03 

END 

CHAIN 

# 

#THE  FINAL  CHAIN  OON6TRUCT  OF  UNIT  MISSION  BEING  MODELED. 

# 

CH  AMMO  INSP-AMvlO  CLERK,*13,CHECKERS, CRANE  CHIEF, RTFL  CWEP,!(vKE;iAMMO 
END 
REPAIR 
* 

#  DEFINE  RELATIVE  PARANETERS  FOR  TOE  REPAIR  OF  DAMAGED  ITEFS. 

# 

FORKLIFT 

$*15,2,1., 180., 80 ,2885.,  1885. 

CRANE 

$*152,1., 180, '0,2885., 1885. 


STACKS 

$FIRENCKU, !.,  MOO  ,380,1560, 1074. 

GENERAL  REPAIR 

$*H,2 

$FIRETEAMl 

END 

INTERNAL  REOONCTTTUTION  TIMES 

# 

#INPUTAMATRJXOFTIL€S,  FOLLOWING  A LETHALITY ETVENT OR  RBOONSmVTlON  EVENT, 
#AT  WHICH  OUIPUTS  ARE  DESIRED. 

# 
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16..30. 

ETC 

OUTPUT 

# 

#1N=UT  THE  DESIRED  OUIWT  OCAMANCS. 

# 

B!NE,1.5,3.7, 10.0, 100.6,1000 
CASUALTIES,  ON 
CHA1N.OFF 
DEPLOYKENT.ON 
DOSE,  ON 

SUMMARY,  PERSONNEL 
DEPDAf*, 1.6,3.7,19.0,100.6,1000. 

LETHALITY,  ON 
ETIPCLON 

NUCLEAR  SUMMARY, ON 
R£XX)ferm/nON,PARTlAL 
RANDOM  NUMBER,  OFF 
END 

REPLICATION 

# 

#INVTTHE  DESIRED  MJMBER  OF  REPLICATIONS. 

# 

76 

END 

REOOABTm/n  ON  EVENT 

* 

#RESE7IS  THE  1NIERNAL  TIME  CLOCK  TO  RESTART  A  SERIES  OF  OUTPUT  TIME  POINTS. 

* 

0., so., 1440. 

END 

HEADING 

# 

#WRTIE  A  NESSACE  AT  THE  BEGINNING  OF  THE  AURA  OUTPUT. 

# 

ASP1E3  AKfvlUNmON  SUPPLY  POINT 
EN> 

00 

STOP 
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#TH1S  IS  AN  EXATPLE  OF  AN  AURA  INPUT  RUN3TREAM  FOR  UNIT  MISSION  IN  A 
^CONVENTIONAL  SCQ^ARIO. 

# 

REPERTOIRE 

WEAPONS 

# 

#THE  OONVENnONAL  WEAPON  USED  IS  NAMED  THRT1 3 

# 

BSBOOM3ARY5EOONDARY 

THRT13,OONVENnONAL 

PCS 

# 

#THEPERSONTELAN3E>5UIFTENr  REQUIRED  FOR  A  MISSION 

# 

FIREMETLPERSONISL 

nREJIE4M,PEPSONT£L 

CRATE 

FRKLFTBA.PORKLffTB.PORKLffT 
FRKLFIOBiPORKLIFro,  PORKUFT 


TRACT0R10,TOUCK5T 
WRE3CKER.TRUCK6T 
B  STACKS 
PROP  STACKS 


CRATE  OP£R,PERSONN2L 
UFT/LOAD  OP,  PERSONNEL 
DUTMY  MAINT,  PERSONNEL 
DUMvIY  SERVC.PERSO'  1TEL 
ETC 

DEPLOYMENT 

# 

#THEDEPLCfY\CNr  PARAMETERS  OF  THE  ASSETS. 

# 

CRATE  511.00, 1420100,1.,  1, 1,  1, 1,  1, 0 
*2,1AC.6 

CRATE  1SS6.00, 1739.50,1.,  1,  1,  1, 1,  1, 0 
*2,t..6,4,.6 


PROP  STACKS,  1322.08, 1075.00,1.,  1, 1, 1, 1, 1, 0 
*2,1,.6,4,.6 

B  STACKS  ,  1406.80,  1001.40,1.,  1,  1,  1,  1,  1,0 
*2,1,.6,4,.6 


TELEPHONE,  1088.14,  180016,1.,  1, 1,  1, 1, 1, 0 
i2,l,.6,4,.6 

TRUCK,  1087.24,  1860.02,1.,  1, 1, 1, 1,  1,  0 

$2,1,  .6, 4,. 6 


FIREMEN  ,  1561.43, 1073.04,  -1.,  1, 1, 1,  1, 1,  0 
*2,1,  .8,4,^ 

PtRETEWM.1651.43107304,-20.,1,1,1,1, 1.0 

*2,1,  .6,4,  .6 

ETC 

OONVENnONAL  LETHALITY  DATA 

# 

#AURA  READS  A  OONVENnONAL  LETHALITY  FILE  VIA  ITP17T  UNIT  MJMEER  2 

# 

ETC 

SECONDARY  EXPLOSIVE 

# 

#IDEI7nFIES  SOME  ASSETS  AS  BEING  POTENTIAL  SOURCES  OF  SECONDARY  EXPLOSIONS. 

JU 

B  SECOMXARY.B  STACKS 
ETC 

DELIVERY  ERRORS 

# 

#DEFITE  THE  DELIVERY  ERRORS  OF  WEAPON  THRT13 

# 

THRT1310., 143,0., 46,0. 

END 
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VOLLEY 

# 

#I7FUT  THE  PARAI^TITISTECESSARY  TO  SPECIFY  AN  ATTACK  OF  AT  LEAST  TWO 
#ROUN36  PER  AIMPOINT  CHOSEN  THERE  ARE  4,  8,  OR  12  ROUNDS  FIRED  PER 
#.MMPOtNT  IN  THIS  SCENARIO. 

# 

THRTlSA, 487., 1622., 01,4,0.,1'W. 

THRTi3,a,487.,i522.,a,4,a,i4a 
THRTl 3,0., 2316., 1622..0,, 12,0., 220. 


THRTl 3,0., 1630.,1772.,0.,12,<X, 220. 
iHRns,a,i63a,707„a,8,o.,na 
ELD 
ULKS 
# 

#THE  ULK  ORGANIZATION  FOR  A  DEFINED  MISSION 

# 

F1REXEN..6 

JPERSONNEL 

|T,1. 

JEi. 

FTREIEAM20. 

JPERSONLEL 

ST,1. 

JE1. 


RECORD  CLERK,*.  ,8. 

JM.2.,26 

JOOAMO  CPERS,TYPIST,RTFL  CHIEF, 0PERAT0R,CRANE  OPER,  CRANE  CHIEF 

tT,i2a,i4a,7a,4a,4a,sa 

JE.8,.7,1.,1.,1.,1. 

JCHETKERS 

$T,8. 

JEl. 


OPERATOR  M.4.,  4. 

JNCO.OOMMO  OPERS,RE*X>RD  CLERK.MAINT  STAFF, REOOV  OFER.SERVC  PERS 
JT, 120, 130., 60., #0., 70., DO. 

SE,.8,.8,1.,1„1.,1. 

$LIFT/LOAD  OP, CRANE  OPER 
$T, 46., 26. 

SEl.,1. 


A  STACKS,  8. 

B  STACKS,#. 

FROP  STACKS,#. 

CSTACKS,3. 

D  STACKS.6.W 
E  STACKS,  14. 

FSTACKS.6M 

ETC 

SUBCHAINS 

# 

#  DEFILE  FUNCTIONAL  STRUCTURES  THAT  REPRESENT  SETS  OFSUETTASKS. 

# 

‘l.FRKLFTOA OPERATOR  A 
*2,FRKLFToB,  OPERA  TOR  B 
*3, FRKLPT9C,  OPERATOR  C 


*14,  MAI  NT  UXLAUTO  TEXH,TRACTOR£,TRAII£R12,TRACTORlO,TRAIL£R26 
•l6,DUNtvIY  MAINT.tXIVWY  SERVO 
•13, B  STACKS,PROP  STACKS 

r>*> 

0RL1LKS 

# 

#  DEFILE  FUNCTIONAL  STRUCTURES  THAT  REPRESENT  MUTUALLY  EXCLUSIVE  CHOICE  FOR 
#1HE  ACOOMTJSHSENT  OF  PART  OF  A  MISSION 

# 

+1,*1,USERSA 
4-2,  *2,  USERS  B 


81 


+3,*3,US£RSC 


+ n,*n, users  m 

EM) 

OOM=OUM)UM<S 

# 

#DEF!M:  FUNCTIONAL  STRUCTURES  WHICH  ARE  WEIGHTED  SUMMATIONS  OF  PARTS. 

* 

l!S«E 


+1,.0C3 

+2,-003 

+3,-003 


DSTACKS,.04 

ESTACKS,.07 

FSTACKS..03 

END 

CHAIN 

# 

#THE  FINAL  CHAIN  OOMTRUCT  OF  UNIT  MISSION  BE1  NO  MODELED 

# 

CH  AfvfvtO  IN5P.ANMO  OERK,*13,CHDCKERS,CT<ANB  CHIEF, RTFU  aHEP,!V«E,lAAMO 
EM) 

REPAIR 

* 

#DEFIM:  RELATIVE  PAKAK*TERS  FOR  THE  REPAIR  Of'  DAMAGED  rFEMS. 

# 

FORKLIFT 

t*I6Al. ,18a, 90, 2085., 1086. 
cram: 

**l6£i.,i8a,ea, 2086.,  less. 


STACKS 

lFIREPSni,l.,MOO.,3Ai.,]&5a,lCr74. 

CEMRAL  REPAIR 
1*14.2 

tFIRETEAMl 

EM) 

INTERNAL  REJOOMT*  .VTION  m*S 

# 

#INPUT  A  MATRIX  OF  TtMES,  FOLLOWING  A  LETHALTrY  EVENT  OR  REXXJMTTIVnON  EVENT, 

#  AT  WHICH  OUTPUTS  ARE  DESIRED. 

* 

16., 30 
END 
OUTPUT 
# 

#INPUTTHE  DESIRED  OUTPUT  OOKfwIATE6. 

# 

CASUALTIES,  ON 
CHAINOFF 
DEPLOYNdTT.ON 
SUMMARY, PERSONNEL 
DEPDNP.LEA  7, 19.0,100.6, 1000. 

LETHALTIY.ON 
RBXMTTTUnONPARrnAL 
REPAIR  REPORT,  FULL 
RANDOM  NUMBER.OFF 
EM) 

REPLICATION 

# 

#IMVTTHE  DESIRED  NUMBER  OF  REPLICATIONS. 

# 

60 

END 

RECONSTITUTION  EVENT 
& 

4f  RESETS  THE  INTERNAL  TEvE  CLOCK  TO  RESTART  A  SCRIES  CP  CUTT’UTTT.fS  POINTS. 

# 

0,00,1440 

EM) 

HEADING 

# 

#WRTTE  A  MESSAGE  ATTHE  BEGINNING  OF  THE  AURA  OUTPUT. 

# 
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ASP1B  AKtdUNmON  SUPPLY  POINT 

END 

OO 

STOP 
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#THtSB  AN  EXAMPLE  OF  AN  AURA  INPUT  RUN3TREAM  FOR  UNTT  MISSION  IN  A 
#CH=MICAL  SCENARIO^ 

# 

REPERTOIRE 

WEAPONS 

# 

#7HE  CHENI1CAL  WEAPON  USED  ENAVEDO^eHELL 

# 

CMEMSHELUTCMC 

FOB 

# 

#THE  PERSONNEL  AND  EXJJIPNCNT  REQUIRED  FOR  A  MISSION 

* 

FIREXCN,PERSONNEL 

FtRETEAMPERSONNED 

crane: 

FRMFT^FXRKLffTS, FORKLIFT 
FRKUTSBiFORKLffTB.FORKUFT 


TRACPOR10.TRUCKBT 
WR£CKER,TRUCK6T 
B STACKS 
PROP  STACKS 


CRAPE  OPER,PERSONP*D 
UFT  "  ON)  OP, PERSONNEL 
DUNMY  MAIPJT.PERSONPPL 

duvwyservo,personnel 

ETC) 

DEFLOYMEPTT 

# 

#THE  DEFLOYKCNT  PARANCTTERS  OP  THE  .ASSETS. 

# 

CRAP*;  611.00,  1420i00,l.,  1,  t,  1,  1,  1,  0 
*2,1,  -6.4,.6 

CRAP*;  1360.00,  1730.60,1.,  1,  1,  1,  1,  1,  0 
*2,V6,0,A 


PROP  STACKS,  1322.08,  1076.00.1.,  1,  1,  1,  1,  1,  0 
*2,1..5,4..6 

B  STACKS  ,  1 406.80,  1001.40,1.,  1,  1,  1,  1,  1,  0 
*2,1, .6, 4,-6 


FIREKEN  ,  1661.43,  1073.04,  •!.,  1,  1,  1,  1,  1,  0 
*2,1,.6,4,.6 

FIRtjreAM,1651.43,1073.04,-2a,l,l,l,l,  1,  0 
*2,1,.6,4,.5 
END 
T.K.C 
# 

#ALUMS  TWE  USER  TO  IPCHGATEDEPLOYVENTr  POINTS  AT  WHICH  A  DDTKXILT  OR  E>£Y 
#JOB  IS  BEING  PERFORMED. 

# 

PERSONPCLA2. 


USER,1,3. 

END 

CEP  ERROR 

# 

thread  the  delivery  errors  expressed  in  circliar  error  probable;  oooe  converts 

#TO  A  STANDARD  DEVIATION. 

# 

CHEM3HEU,00.,00.,0. 

END 

CEPTVE 

# 

#IPPUTTHETARCET LOCATION  ERRORS  EXPRESSED  INCTRCULAR  ERROR  PROBABLE 

# 

00. 

END 
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INOCMNC  FIRE  DIRECTION 

# 

#  ORIENTS  THE  INCOMING  FIRE  DIRECTION  WITH  RESPECT  TO  THE  UN7T  COORDINATE 
#SYSIEM 

# 
to 
EM) 

W1M)DCRBST!0N 

* 

#  ORIENTS  THE  WIND  DIRECTI ON  WJTH  RESPECT  TO  TOE  UNIT  COORDINATE:  SYSTEM. 

# 

45 

EM) 

D06E  PARAMETERS 

# 

#SCT  MAXIMJM  DOSAGE  TO  EE  OOf«IDERED  AN  IffcTANT  CASUALTY. 

# 

MAX  DOSE,  5. 

# 

#SETS  FROMT  SLOPE  TO  MODEL  THE  VARYING  SEJ-EmVITY  OF  1M3-VIDUALS  "O  DC6ES 
#OF  VARIOUS  CHEMICALS. 

# 

FROnrT,l,.245 

EM) 

IV  DOSE 

# 

#ENABLES  USER  TO  CONTROL  TIE  INTRAVENOUS  DOSE  OONMANO  ACTTV7TY. 

# 

IVD06E.0FF 

EM) 

CONTAMINATED  USAGE 

# 

#  ALLOWS  LEE  OF  SELECTED  ITEMS  OF  EQUIPVEJVr  WHEN  IT  IS  CONTA.\HJATEn 

# 

ALL 

EM) 

TOMC  DISPERSION  DATA 

# 

#AURA  READS  A  TCOOC  DISPERSION  DATA  FILE  VIA  IN=l  IT  UNTTNUVEER  4. 

# 

EM) 

PERSISTEMOE 

# 

#  ENABLES  THE  MODIFICATION  OF  TOE  PERSISTENCE  TIME  FOR  CHEMICAL  AGENIS  ON 
#SFBCIFIED  ASSETS  FROM  THAT  PRODUCED  BY  NUSSE 

# 

CHEM3HELL 

FRKLFT.S.S 

EM) 

FATIGUE 

# 

#DKTNKS  SPECIFIC  JOBS  AS  MORE  DEMAMXNG  THAN  OTHERS. 

# 

TREMENO.4555,1188. 

EM) 

HEAT  STRESS 

# 

#  ALLOWS  THE  SUBSTITUTION  OF  SPECIFIC  VALUES  FOR  VARIOUS  METBCROLOGKAL 
#OOM)mON5  THAT  CAN  IM>ACT  HEAT  STRESS  EFFECTS  ON  PERSONNEL. 

* 

CU.1.6# 

1,4.  .M 
S.38.0 

DELIVERY  ERRORS 

# 

#DEFINE  THE  DELIVERY  ERRORS  OP  WEAPON  CHEM3HELL 

# 

CHEM3HELL,10.,140.,8.,4S.,0. 

EM) 

VOLLEY 

# 

#ITPUTTHE  PARAMETERS  MJCESSARY  TO  SPECIFY  AN  ATTACK  OF  AT  LEAST  TWO 
#ROUM)6  PER  AIMOINT  CHCSEN 
# 

CHEM3HEU,0. , 487. ,  1  KB.  ,0.,4,0. ,  1 40. 

CHEMSHEiL,a,487.,i6a2.,a,4ia,i40. 

CHENBHELL,a,2«15.,IS22.,a,l2,alm 


CHEM3HELL.0., 1630., 1772., 0.0,12,0.,220. 


85 


CHEX6HELL,0.,163a,707.,ao,8,a,MO. 

EM) 

AGENT 

CHEMSHEL'.O 

EM) 

LINKS 

# 

#THE  UM<  ORGANIZATION  TOR  A  DEFINED  MISSION 

# 

FIREMEN,-# 

1PERSONNEL 

JT.I. 

1E.1. 

nRCTEAM,2a 

IPERSONML 

*T,1. 

JE.1. 


OPERATOR  M.4.,4. 

1NOC\OONMO  OPERS.R3O0RD  CLERK.MAIN7T  STAFF, RECOV  OPERSERVC  PERS 

tT,t30.,isa,60.,#a,7a,#a 

|£.8,.*,I.1I„J.,L 

Juft/load  op, cram:  oper 

JT,«.,26, 

lEl.,1. 


A  STACKS,#. 

B  STACKS,#. 

PROP  STACKS,#. 

C  STACKS,#. 

D  STACKS,  6.9# 

E  STACKS,  M. 

F  STACKS^,## 

EM) 

SUBCHAINS 

* 

#  DEFINE  FUNCTIONAL  STRUCTURES  THAT  REPRESENT  SETS  OF  SUBTASKS. 

# 

*  1  .FRKLFTB  A.OPERATOR  A 
*2,  FRKLFTSB,  OPERATOR  B 

•3,rpjam>c,  operator  c 


•  1 4.MAINT  LDR^AI  /TO  TEKR,TRACT0RS,TRAILER1 2.TRACT0RI  0/1RAUJER25 
•I6.DUNMY  MAI  NT,  DUMMY  SERVO 

•  i  «,B  STAC  S.PROP  STACKS 
END 

ORUNKS 

• 

#  DEFINE  FUNCTIONAL  STRUCTURES  THAT  REPRESENT  MUTUALLY  EXCLUSIVE  CHOICE  FOR 
#THE  AOOONELEHVENT  OF  PART  OF  A  MISSION 

# 

+1,M,USERSA 
+V2.USERSB 
+#,*#,  USERS  C 


+11, *11, USERS  M 
EM) 

COMPOUND  LINKS 

# 

#  DEFINE  FUNCTIONAL  STRUCTURES  WHICH  ARE  WEIGHTED  SUMMATIONS  OF  PARTS 

# 

l!WE 


+1,.0«S 

+2,.oes 

+S,.0#3 


DSTACKS.W 
E  STACKS. 07 
F  STACKS- 03 
EM) 
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CHAIN 

# 

#THE  FINAL  CHAIN  CONSTRUCT  OF  UNIT  MISSION  BEING  MODELED. 

# 

CH  AMHO  INSP,AKMO  OCTIK,*  IS,  CHECKERS,  CRAhE  CHIEF, RTFL  CHIEF, IKEEIIAKN40 
ETC 

DEGRADATION 

# 

#  ASSOCIATE!  A  MOPP  OOCE  NUMSER  AM)  A  T.K.G  OOO0  NUMBER  WTTH  A  PERFORMANCE 

#  DEGRADATION  VALUE 

# 

0,1,1. 

0,2,1. 

0,8,1. 


4.7,  .4 

4.8,  J 
ETC 
REPAIR 
# 

#DEFINE  RELATIVE  PARAMETERS  FOR  THE  REPAIR  OF  DAMAGED  TIEKC. 

# 

FORKLIFT 

8*16,2,1., 180., W..288S., 1885. 

CRANE 

J'15,21., 180, 00,2986., 1880. 


STACKS 

lFIR£?uEN,l,l.,140a,S80.,lS50.,lCrH. 

GENERAL  REPAIR 
$*14£ 

InRETEAM,! 

END 

OUIPUT 

# 

#1NPUTTHE  DESIRED  OUTPUT  COMMANDS. 

# 

CASUALTIES,  ON 
CHAlHOfT 
DBPUmCNr.ON 
DC6EON 

SUMMARY, PERSONNEL 
DEPDKP, 1.6,3.?, 10.0,1006,1000 
LETHALITY, ON 
REOOhErmVnOKPARriAL 
REPAIR  REPORT,  FULL 
END 

REPLICATION 

# 

#INPUT1HE  DESIRED  NUKGER  OF  REPLICATIONS. 

* 

100 

END 

REOOICTmmON  EVENT 

# 

#RESETS  THE  INTERNAL  TIMS  CLOCK  TO  RESTART  A  SERIES  OF  OUIPUT  TIMS  PdNTTS. 

# 

a, ao, ’4a 

END 

INIERNAL  REOONSTnVnON  TIMES 

# 

#  INPUT  A  MATRK  OF  TIMES,  FOLLOWING  A  LEIUALITY  EVENT  OR  REOONSrriVnoN  EVENT, 
#AT  WHICH  OUTPUTS  ARE  DESIRED 

* 

16.^0., 66., 90., 120. 

END 

HEADINC 

Ji 

#WRITC  A  KCSSACE  ATTHE  EEX3INN1NC  OF  THE  AURA  OUTPUT. 

# 

ASPIB  AMMUNITION  SUPPLY  POINT 

END 

ao 

STOP 
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APPENDIX  B 

Index  of  Default  Values  for  AURA  Input  Commands  and  Output  Options 
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The  following  tables  list  the  default  values  for  all  AURA  input  commands 
and  output  options.  They  are  separated  into  four  categories  which  are:  non¬ 
scenario  dependent,  chemical  scenario  dependent,  nuclear  scenario  dependent,  and 
conventional  scenario  dependent.  Within  each  of  these  categories  they  are 
separated  into  input  commands  and  output  options  and  listed  alphabetically.  In 
the  following  tables,  some  of  these  have  a  default  value  of  "OFF".  In  this  case, 
the  code  will  not  model  this  parameter  unless  it  is  included  in  the  AURA  input 
file.  Some  of  the  parameters  whose  defaults  are  "OFF"  also  have  default  values 
for  the  parameters  associated  with  them.  These  defaults  will  not  be  used  by 
AURA  unless  the  command  or  option  is  included  in  the  AURA  input  file. 
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NON-SCENARIO  DEPENDENT  COMMANDS 


INPUT  COMMANDS 


DEFAULTS 


ACQUISITION  PROBABILITY 

target  acquisition  probability  . . . jp 


CEP  ERROR 

precision  error  . 0,0 

mean  point  of  impact  error  . 0.0 

standard  deviation  in  height  of  burst  . 0.0 


CEP  TLE 

target  location  error,  expressed  as  circular  error  probable  .  0,0 


CHAINS  . 

CREW  . 

COMPOUND  LINKS 


This  is  required  in  every  scenario 

OFF 

OFF 


DECISION  RULES 

PRIORITY,  VERSATILITY  or  ORDER  . 

SIGNIFICANCE,  required  fractional  improvement  needed  . 

SICKLV,  sickness  degradation  level  . 

FINISH  REPAIR,  relative  gain  for  finishing  a  needed  repair  ... _ 


VERSATILITY 

0.005 

0.75 

2.0 


DELIVERY  ERROR 

precision  error  in  range  . 

mean  point  of  impact  error  in  range  .... 

precision  error  in  deflection  . 

mean  point  of  impact  error  in  deflection 
error  in  height  of  burst  . . 


0.0 

0.0 

0.0 

0.0 

0.0 


DEPLOYMENT 

EXPENDABLE 


This  required  in  every  scenario 
OFF 


FAILURE  RATE 


FATIGUE  . 0FF 

relative  fatigue  rate  . 0.2639  SLUNITs/minute 

relative  demand  for  stored  rest  .  1235.0  SLUNITs 

minimum  amount  of  sleep  required  by  assets  . 240.0  SLUNITs 

maximum  amount  cf  sleep  permitted  for  assets  .  1520.0  SLUNITs 


. This  is  required  in  every  scenario 

no  a  xii  ii  adttv 

Ul%nt  .VMi.au  .  * 

largest  increment  per  allocation  step  . X.O 


HEADING 


OFF 
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NON-SCENARIO  DEPENDENT  DEFAULTS 


INPUT  COMMANDS 


DEFAULTS 


HEAT  STRESS 

ambient  temperature  .  20.0  degrees  Celsius 

relative  humidity  .  20.0% 

wind  speed  .  3,0  meters/second 

maximum  allowable  metabolic  rate,  initial  MOPP  .  1.E35 

maximum  allowable  metabolic  rate,  alternate  MOPP  1.E35 

metabolic  rate  .  250.0  watts 

MOPPO  clothing  parameter  for  clo  . . .  1.43 

MOPP1-MOPP3  clothing  parameter  for  clo  2.07 

MOPP4  clothing  parameter  for  clo .  2.32 

MOPPO  clothing  parameter  for  im/clo  . .  0.34 

MOPP1-MOPP3  clothing  parameter  for  im/clo  . .  0.22 

MOPP4  clothing  parameter  for  im/clo  . .  0,15 

gamma  wind  correction  factor  for  clo  . .  0.26 

gamma  wind  correction  factor  for  im/clo  . . . .  0.38 

skin  temperature  .  36.0  degree,  "tlsius 

percent  dehydration  .  0.0% 

days  of  acclimatization  . 12.0 

INCOMING  FIRE  DIRECTION 

angle  of  incoming  fire  direction  .  0 

INTERNAL  RECONSTITUTION  TIMES  .  0 


LINKS  .  This  is  required  in  every  scenario 

maximum  effectiveness  .  1.0(100%) 

maximum  number  of  items  that  can  be  assigned  to  a  link  . , .  1.E35 

number  of  effective  assets  below  which  effectiveness  is  minimum  ....  0.0 

minimum  effectiveness  .  0.0(0%) 

maximum  amount  to  be  allocated  in  any  one  pass  . . .  0.5 

effectiveness  level  below  which  a  substitution  will  not  be  made  .......  0.1  (10%; 

MISS  DISTANCE  .  OFF 


MODE 

CODE,  ON  or  OFF  .  OFF 

CULL,  ON  or  OFF  . .  OFF 

DEBUG,  ON  or  OFF  .  OFF 

PRIORITY,  ON  or  OFF  .  OFF 

INDIVIDUAL  DOSES,  ON  or  OFF  .  ON 

STOCHASTIC,  ON  or  OFF  .  OFF 


NAMES 


This  is  required  in  every  scenario 


urr 


ORLINKS 


OFF 
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NON-SCENARIO  DEPENDENT  COMMANDS 


INPUT  COMMANDS 


DEFAULTS 


OUTPUT  .  OFF 

RECONSTITUTION  EVENTS  .  0 

REINFORCEMENTS/LOSSES  .  OFF 

RELIABILITY  OF  WEAPONS 

single  warhead  reliability  .  1.0 

reliability  of  a  volley  of  warheads 

REPAIR  .  OFF 

MAXIMUM  NUMBER,  maximum  #  of  repairs  at  one  time  ........  SO 


REPERTOIRE  .  This  is  required  in  every  scenario 

REPLICATIONS  .  ""his  is  required  in  every  scenario 

REST  .  OFF 


ROUND  . 

SEEDS  (Random  Number)  . 

STOP  . 

SUBCHAINS  . 

TEMPORARY  LOSSES/RETURN  TO  DUTY  .. 
TIME  DEPENDENT  (LINK)  DEGRADATION 


»  OFF 

•  OFF 

This  is  required  in  every  scenario 
.  OFF 

•  OFF 
••  OFF 


TIREDNESS  .  OFF 

minimum  SLUNITs  below  which  assets  will  be  forced  to  rest  ......  o.O  SLUNITs 

maximum  SLunits  above  which  assets  may  not  rest  ..... _ _  1519.99  SLUNITs 

minimum  duration  of  rest  . . .  240.0  SLUNITs 


ceiling  on  the  number  of  cumulative  SLunits  . .  1520.0  SLUNITs 

initial  SLunits  for  asset  at  start  of  each  replication  1520.0  SLUNITs 


TLE 

x-coordinate  of  the  target  location  error  .  0.0 

y-coordinate  of  the  target  location  error  ..................................  o.O 

TRACE  LINK  USAGE  .  OFF 

VOLLEY  .  OFF 

WIND  DIRECTION 

angle  of  the  wind  direction  . . .  0 
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NON-SCENARIO  DEPENDENT  DEFAULTS 


OUTPUT  OPTIONS 

DEFAULTS 

CHAIN  . , . 

.  ON 

PF-PPMP  . . 

DEPLOYMENT  P>  OT  , . 

r>UMP$  . , . 

niiMPo  '  . . . . . . . , . 

FATIGUE  . 

.  OFF 

INPUT  LISTING  . 

.  ON 

l.RTHAI.ITY  . 1T . 

.  ON 

OPTIMIZE  . 

PARTICULAR  ASSETS  . 

.  ACC* 

POSTURE  .  />*?» 

PRINT7  . 

RANDOM  NUMBER  . 

.  AM 

RECONSTITUTION  .  OFF 

REPAIR  REPORT  .  ntr 

REPLICATION  . 

. . .  AFF 

SELECTIVE  PLOT  .  /mu 

SUMMARY  . 

TIMER  . 

. . .  AFF 

WEAPON  .  OFF 
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CHEMICAL  SCENARIO  DEFAULTS 


INPUT  COMMANDS 


DEFAULTS 


AGENT 

agent  type  (G,  V,  or  H)  .  G 

ALARM  .  OFF 

CONTAMINATED  USAGE .  OFF 

Must  MOPP,  ON  or  OFF  OFF 

DEGRADATION  .  OFF 

MOPP  code  .  4 

toxic  kill  criteria  code  number  ...» .  1 


DOSE  PARAMETERS 

DOSE  illNS,  bL  b2,  Ih3, . .  *t  bXO  .......................................  .05, .10, .15, *25, .35, .45, .55, .d5, .75, .85, 1.0 

MAX  DOSE  .  10.0 

PROBIT  .  OFF 

agent  number  agent  type  default  probit  slope 


1  non-persistent  0.0 

2  persistent  0.0 

3  blistering  0.0 


INTRAVENOUS  DOSES 

IVDOSE,  ON  or  OFF  .  OFF 

INHALATION,  einbal .  1.0 

PERCUTANEOUS,  eperc  . .  1.0 

MOPP  .  OFF 

fraction  of  vapor  dosage  MOPPO-MOPP2=1.0,  MOPP3=0.0,  MOPP4=0.0 

fracton  of  percutaneous  dosage  MOPP0=1.0,  MOPPl=.2,  MOPP2=.l, 

MOPP3=.025,  MOPP4=0.0 

ALL  CLEAR,  YES  or  NO . .  YES 

PROXIMITY,  distance  . .  1.E35 


RECONSTITUTION,  YES  or  NO  . — .  NO 

RECOVERY  TIME,  time  to  realize  no  contamination  ...........  30.0  (minutes) 

ROUND,  YES,  false  recognition  time  or  ROUND,  NO .............  ROUND, YES,  10.0  (minutes) 

TIME  SPREAD,  fraction  of  time  needed  to  change  MOPP 


posture .  0.2 

PERSISTENCE 

ratio  of  evaporation  time .  1.0 


SUBLETHAL  DOSE  DEGRADATION .  Performance  degradation  of  a  physically 

demanding  task  (i.e.  gunner) 

T.K.C.  (TOXIC  KILL  CRITERIA) 

toxic  kill  criteria  code  number  . . . . .  4 

dosage  multiplier  . . . . .  1.0 


TOXIC  DISPERSION  DATA 


Required  in  this  scenario 


NUCLEAR  SCENARIO  DEFAULTS 


INPUT  COMMANDS 

DOSE  PARAMETERS 
DOSE  BINS,  bl,  b2,  b3, ...  blO 

MAX  DOSE,  maximum  dosage  value 

NUCLEAR  VULNERABILITY  DATA  _ 


SHIELDING 


posture  posture  number 

(a4>) 

open 

1 

open-thermally 

shielded 

2 

(neutron,neutron)  ~__ 

(neut  >n .gamma)  - 

(gamma .neutron)  _ _ 

(gamma&unma^ 

foxhole 

3 

(neutron,neutron) 

tneutron^amma) _ 

(gamma  .neutron)  ___ 
(gamma^amma)  __ 

armored 

4 

(i  eutronaieutron) 

(neutron^amma) _ 

(gamma,neutron)  —  , 
(gamma, gamma) 

personnel 

(neutron, neutron) 

carrier 

(neutron, gamma)  __~.. 

tank 

5 

(gamma  .neutron) _ 

(gamma^amma)  - 

(neutron,neutron)  «, 
(neutron^amma)  «. 
(gamma^ieutron)  ». 
(gamma^amma)  «. 

SUBLETHAL  DOSE  DEGRADATION  _ 


THERMAL 
ATMOSPHERE,  quality 

(POOR,  AVERAGE,  or  GOOD)  . . . . 

UNIFORM,  type  (SUMMER  or  WINTER)  ... _ 

YIELD  . 


DEFAULTS 


5.0,75.0,150.0,300.0,450.0,530.0,830.0,1100.0,1500.0, 

4500.0 

8000.0 

Required  for  h.is  scenario 


Fraction  of  dosage  of  type  b  in  the  posture  due  to  an 
incident  dosage  of  type  a 

1.0  (100%) 

0.0 

0.0 

1.0 


1.0 

0.0 

0.0 

10 


0.3 

0.0 

0.0 

0.3 


0.9 

0.0 

0.0 

0.9 


0.5 

0.0 

0.0 

0.5 

Performance  degradation  of  a  physically  demanding 
task  (i.e.  gunner) 


AVERAGE 

SUMMER 

Required  in  this  scenario 
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CONVENTIONAL  SCENARIO  DEFAULTS 


INPUT  COMMANDS  DEFAULTS 

CONVENTIONAL  LETHALITY  DATA  .  Required  in  this  scenario 

SECONDARY  EXPLOSIVE  .  OFF 
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OUTPUT  OPTIONS 


CHEMICAL  SCENARIO  DEFAULTS 

DEFAULTS 

DOSE  .  OFF 

NUCLEAR  SCENARIO  DEFAULTS 

BINS  . OFF 

DOSE  . . OFF 

ETIPCI  .  ON 

NUCLEAR  SUMMARY  .  OFF 
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This  page  intentionally  left  blank 
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APPENDIX  C 

Index  of  AURA  Input  Commands  and  Output  Options 
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This  page  intentionally  left  blank 
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The  following  table  is  an  alphabetical  listing  of  all  current  AURA  input 
commands  and  output  options  with  the  corresponding  page  of  the  report  which 
describes  them. 
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INPUT  COMMANDS 


PAGE 


ACQUISITION  PROBABILITY  .  29 

AGENT  .  29 

ALARM  .  14 

CEP  ERROR  .  30 

CEP  TLE  .  31 

CHAINS  .  51 

CREW  .  52 

COMPOUND  LINKS  .  52 

CONVENTIONAL  LETHALITY  DATA  .....  38 

CONTAMINATED  USAGE .  14 

DECISION  RULES .  56 

DEGRADATION  .  22 

DELIVERY  ERROR  .  31 

DEPLOYMENT  .  22 

DOSE  PARAMETERS  .  38 

EXPENDABLE  .  15 

FAILURE  RATE .  16 

FATIGUE  .  43 

GO  .  57 

GRANULARITY  .  16 

HEADING  .  58 

HEAT  STRESS  .  44 

INCOMING  FIRE  DIRECTION .  32 

INTERNAL  RECONSTITUTION  TIMES....  58 

INTRAVENOUS  DOSES  .  39 

LINKS  .  45 

MISS  DISTANCE  .  33 

MODE  .  58 

MOPP  .  24 

NAMES  .  13 


PAGE 


NUCLEAR  VULNERABILITY  DATA  . .  40 

\OFFSET  .  26 

ORLINKS  .  54 

OUTPUT  .  60 

PERSISTENCE  .  41 

RECONSTITUTION  EVENTS  .  67 

REINFORCEMENTS  /  LOSSES  .  17 

RELIABILITY  OF  WEAPONS  . .  33 

REPAIR  .  18 

REPERTOIRE  .  13 

REPLICATIONS  .  67 

REST  .  26 

ROUND  .  34 

SECONDARY  EXPLOSIVE  .  20 

SEEDS  (Random  Number)  67 

SHIELDING  .  27 

STOP  .  68 

SUBCHAINS  .  55 

SUBLETHAL  DOSE  DEGRADATION  .  48 

TEMPORARY  LOSSES /RETURN  TO  DUTY....  20 

THERMAL  .  41 

TIME  DEPENDENT  (LINK)  DEGRADATION..  49 

TIREDNESS  .  21 

T.K.C.  (TOXIC  KILL  CRITERIA)  .  28 

TLE  .  34 

TOXIC  DISPERSION  DATA  .  42 

TRACE  LINK  USAGE  .  68 

VOLLEY  .  35 

WIND  DIRECTION  .  36 

YIELD  .  37 


OUTPUT  OPTIONS 


PAGE 

PAGE 

BINS  . 

.  fid 

CASUALTIES  . 

.  fid 

CHAIN  . 

.  fid 

DEPDMP  . 

. .  fid 

DEPLOYMENT  PLOT  . 

DOSE  . 

.  fis 

DUMP8  . 

.  fis 

DUMP9  . 

.  fis 

ETIPCI  . 

.  fifi 

FATIGUE  . . . 

. .  er>  ciiMMiBV  . 

.  fifi 

INPUT  LISTING  . 

.  fifi 

LETHALITY  . 

.  fi7 

NUCLEAR  SUMMARY  .  . . 

.  63 
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No  Of  No  of 

Copies  Organization  Copies  Organization 


2  Administrator 

Defense  Technical  Info  Center 
ATTN:  DTIC-DDA 
Cameron  Station 
Alexandria,  VA  22304-6145 

1  HQDA  (SARD-TR) 

WASH  DC  20310-0001 

1  Commander 

US  Army  Materiel  Command 
ATTN:  AMCDRA-ST 
5001  Eisenhower  Avenue 
Alexandria,  VA  22333-0001 


1  Commander 

US  Army  Missile  Command 
ATTN:  AMSMI-RD-CS-R  (DOC) 

Redstone  Arsenal,  AL  35898-5010 

1  Commander 

US  Army  Tank-Automotive  Command 
ATTN:  AMSTA-TSL  (Technical  Library) 
Warren,  Ml  48397-5000 

1  Director 

US  Army  TRADOC  Analysis  Command 
ATTN:  ATRC-WSR 

White  Sands  Missile  Range,  NM  88002-5502 


1  Commander 

US  Army  Laboratory  Command 
ATTN:  AMSLC-DL 
Adelphi,  MD  20783-1145 


(dm.  only)  i  Commandant 

US  Army  Infantry  School 
ATTN:  ATSH-CD  (Security  Mgr.) 
Fort  Banning,  GA  31905-5660 


2  Commander  (Uneioo*.  only)  i  Commandant 


US  Army,  ARDEC 

ATTN:  SMCAR-IMI-I 

Picatinny  Arsenal,  NJ  07806-5000 

2  Commander 

US  Army,  ARDEC 

ATTN:  SMCAR-TDC 

Picatinny  Arsenal,  NJ  07806-5000 

1  Director 

Benet  Weapons  Laboratory 
US  Army.  ARDEC 
ATTN:  SMCAR-CCB-TL 
Watervliet,  NY  12189-4050 

1  Commander 

US  Army  Armament,  Munitions 
and  Chemical  Command 
ATTN:  SMCAR-ESP-L 
Rock  Island.  IL  61299-5000 

1  Director 

US  Army  Aviation  Research 
and  Technology  Activity 
ATTN:  SAVRT-R  (Library) 

M/S  219-3 

Ames  Research  Center 
Moffett  Field,  CA  94035-1000 


US  Army  Infantry  School 
ATTN:  ATSH-CD-CSO-OR 
Fort  Banning,  GA  31905-5660 

1  Air  Force  Armament  Laboratory 
ATTN:  AFATL/DLODL 

Eglin  AFB,  FL  32542-5000 

Aberdeen  Proving  Ground 

2  Dir,  USAMSAA 

ATTN:  AMXSY-D 

AMXSY-MP,  H.  Cohen 
1  Cdr,  USATECOM 

ATTN:  AMSTE-TD 

3  Cdr,  CRDEC,  AMCCOM 

ATTN:  SMCCR-RSP-A 
SMCCR-MU 
SMCCR-MSI 

1  Dir,  VLAMO 

ATTN:  AMSLC-VL-D 
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No.  of 

No.  of 

Conies 

Organization 

Conies 

Organization 

1 

Office  of  the  Secretary  of  Defense 

Joint  Chemical  Warfare 

Joint  Test  Force 

Suite  300,  Five  Skyline  Place 

5111  Leesburg  Pike 

Falls  Church,  VA  22041 

2 

Commander 

U.S.  Army  ARDEC 

ATTN:  SMCAR-FSS, 

Mr.  Ostuni 

Mr.  Brooks 

Picatinny  Arsenal,  NJ  07806-5000 

1 

HQDA 

OASA  (RDA) 

ATTN:  SARD-DOS,  MAJ  Gary  R.  Davis 
WASH  DC  20310-0103 

1 

CDR 

CATA-NSC 

ATTN:  ATZL-TAC-DC,  CPT  H.  Lee 

Fl  Leavenworth,  KS  66027 

10 

C.I.A 

ATTN:  OIR/DB/Standard 

GE-47  HQ 

Washington,  DC  20505 

1 

Commander 

HQ  AMCCOM 

ATIT4:  AMSMC-IMP-IL 

Rock  Island,  IL  61299-7300 

2 

Director 

Defense  Nuclear  Agency 

ATTN:  STBE, 

Dr.  D.  Auton 

Dr.  R.  Young 

1 

Commander,  USACECOM 

R&D  Technical  Library 

ATTN:  ASQNC-ELC-I-T,  Myer  Center 

Fort  Monmouth,  NJ  07703-5301 

Washington,  DC  20305 

5 

Commander 

U.S.  Army  Harry  Diamond  Laboratories 

2 

Commander 

Defense  Nuclear  Agency/Field  Command 

ATTN:  FCPR, 

MAJ  Fleming 

ATTN:  SLCHD-NW-RA 

2800  Powder  Mill  Road 

Adelphia,  MD  2078’ 

CPT  Thorton 

Kirtland  AFB,  NM  87115 

2 

Director 

U.S.  Army  Missile  and  Space  Intelligence  Center 
ATTN:  AIAMS-YDL 

3 

DA/ODCSOPS 

Pentagon 

ATTN:  DAMO-ZDF,  Mr.  Wolpert 

AIAMS-TSL 

Redstone  Arsenal,  AL  35898-5500 

DAMO-ZXG,  Mr.  Patterson 
DAMO-ZDF 

Washington,  DC  20310-0404 

2 

Commander 

TRAC-WSMR 

ATTN:  ATRC-WSR,  Mr.  Belk 

ATOR-TSL 

1 

Commander 

U.S.  Army  Materiel  Command 

White  Sands  Missile  Range,  NM  88002-5522 

ATTN:  AMCDRA-AT 

5001  Eisenhower  Avenue 

Alexandria,  VA  22333-0001 

2 

Director 

TRAC-FLVN 

ATTN:  ATRC-FTC,  CPT  Perry 

ATRC-F,  Dr.  Robert  LaRocque 

Ft.  Leavenworth,  KS  66027 

106 


No.  of 

Conies  Organization 

1  Director 
TRACRPD 

ATTN:  ATRC-RPR,  Mr.  Radda 
Ft.  Monroe,  VA  23651-5143 

2  Commander 

U.S.  Army  Aviation  Logistics  Center 
ATTN:  ATSP-CD, 

CPT  White 
Mr.  Pollack 
Ft.  Eustis,  VA  23604 

3  Commander 

U.S.  Army  Combined  Arms  Combat 
Developments  Agency 
ATIN:  ATZL-CAS-SP,  CPT  DeWulf 
ATZL-CAP, 

COL  Henderson 
CPT  Grand 

Fl  Leavenworth,  KS  66027 

2  U.S.  Army  Nuclear  and  Chemical  Agency 
ATTN:  MONA-WE 

MONA-CM,  MAJ  Joe  Fernandez 
7500  Backlick  Road,  Bldg  2073 
Springfield,  VA  22150-3198 

1  Director 

TRAC-Ft.  Lee 
ATTN:  ATRC-OS 
Fl  Lee,  VA  23801-6000 

3  Director 

Concepts  Analysis  Agency 
ATTN:  CSCA, 

Mr.  D.  Hurd 
LTC  Barrett 
Mr.  Chandler 
8120  Woodmont  Avenue 
Bethesda,  MD  20014 

1  Commandant 

U.S.  Army  Air  Defense  Artillery  School 

ATTN:  ATZK-CD 

Bldg  5800 

Ft.  Bliss,  TX  79916 


No.  of 

Copies  Organization 

1  Commandant 

U.S.  Army  Armor  School 

ATTN:  ATZK-CP-SD,  Mr.  Hekemeyer 

Ft.  Knox,  KY  40121 

1  Commander 

U.S.  Army  Engineering  School 

ATTN:  ATSE-CDM 

Ft.  Leonard  Wood,  MO  65473-6620 

1  Commander 

U.S.  Army  Field  Artillery  School 
ATTN:  ATSF-CD 
Fl  Sill,  OK  73503 

1  Commandant 

U.S.  Army  Transportation  School 
ATTN:  ATSP-PD-C 
Fl  Eustis,  VA  23604 

2  Commander 

U.S.  Army  Missile  and  Munitions  Center 
and  School 
ATTN:  ATSK-CD 
Redstone  Arsenal,  AL  35898 

1  Commander 

U.S.  Army  Quartermaster  School 
ATTN:  ATSM-CDC 
Fl  Lee,  VA  23801 

1  Commander 

U.S.  Army  Signal  Center  &  School 
Directorate  of  Combat  Developments 
Ft.  Gordon,  GA  30905 

4  Commandant 

U.S.  Army  Chemical  School  Directorate 
of  Combat  Developments 
ATIN:  ATZN-CM-CC, 

LTC  Gary  Stratton 
Mr.  B.  Gould 
Ms.  Sherry  Barnes 
Ms.  Rena  Seals 
Ft.  McCieiian,  AL  5620i 
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No.  of 

Copies  Organization 

1  US  Army  War  College 

ATTN:  Mr.  Carl  Barton 
Box  531 

Carlisle  Barracks,  PA  17013-5050 

1  Commander 

Armed  Forces  Radiobiological  Research 
Institute 

National  Naval  Medical  Center 
ATTN:  Mr.  William  Jackson 
Bethesda,  MD  20014 

2  Commander 
Combined  Arms  Center 
Scores  Working  Group 
ATIN:  ATZL-CAD-LN 
Ft.  Leavenworth,  KS  66027 

2  Commander 

Naval  Surface  Warfare  Center 
ATIN:  Code  31-TJY, 

Mr.  Yencha 
Mr.  P.  Kirk 
Dahlgren,  VA  22448 

1  President 

Center  for  Naval  Analyses 
4401  Ford  Avenue 
P.O.  Box  16268 
Alexandria,  VA  22302-0268 

2  Walter  Reed  Army  Institute  of  Research 
Division  of  Medicine 

Department  of  Respiratory  Research 
ATTN:  SGRD-UWH-E, 

.  MAJ  Gary  R.  Ripple,  MD 
LTC  Kenneth  Torrington 
Washington,  DC  20307-5100 

3  Institute  for  Defense  Analysis 
ATTN:  Mr.  Graham  McBryde 

Mr.  M.  Kerlin 
Dr.  M.  Charren 
1801  N.  Beauregard  Street 
Alexandria,  VA  22311 


No.  of 

Copies  Organization 

3  U.S.  Army  Personnel  Command 

ATTN:  DAPC-MOP,  H.  Rowland  Ludden 
TAPC-MOP, 

MAJ  M.  Brice  Elliot 
CPT  I.  McMahon 
200  Stovall  Street 
Alexandria,  VA  22332-0432 

1  U.S.  Army  Chief  of  Staff 
ATIN:  DACS-DPZ-A 
The  Pentagon 
Washington,  DC  20310 

3  U.S.  Army  Deputy  Chief  of  Staff 
for  Operations  and  Plans 
ATIN:  DAMO-SWC,  LTC  Gordon  Miller 
DAMO-ZD, 

Mr.  John  Riente 
Mr.  James  Metzger 
The  Pentagon 
Washington,  DC  20310 

1  Defense  Nuclear  Agency 
6801  Telegraph  Road 
Alexandria,  VA  22310 

2  Office  of  the  Surgeon  General 
5111  Leesburg  Pike 

ATTN:  DASG-HCO-P,  MAJ  Ray  Keith 
DASG-HCD,  MAJ  Robert  Eng 
Falls  Church,  VA  22041 

1  U.S  Army  Engineer  Studies  Center 
ATTN:  ESC-EO 
Casey  Bldg  2594 
Ft.  Bclvoir,  VA  22060-5583 

1  Commanding  General 

U.S.  Army  Operational  Test  and 
Evaluation  Agency 
Park  Center  IV 
4501  Ford  Avenue 
Alexandria,  VA  22302-1428 
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No.  of 

Copies  Organization 


No.  of 

Copies  Organization 


2  Director 
TRAC-MTRY 

Naval  Postgraduate  School 

ATTN:  LTC  Vernon  M.  Bettencourt,  Jr. 

MAJ  R.  Wimberley 
P.O.  Box  8692 
Monterey,  CA  93943-0692 

1  U.S.  Army  Command  and  General 

Staff  College 

Office  of  the  Commandant 
Fl  Leavenworth,  KS  66027-6900 

3  JAYCOR 

ATTN:  Mr.  J.  David  Claiborne 
Mr.  Hubert  Lockerd 
Mr.  William  Jenkins 
P.O.  Box  87 
Edgewood,  MD  21040 

3  EAI  Corporation 

ATTN:  Mr.  Dennis  Metz 
Mr.  Bruce  Fischer 
Mr.  S.  Matthew  Hutton 
1308  Continental  Drive,  Suite  J 
Abingdon,  MD  21009 

2  Science  Applications  International 

Corporation 
ATTN:  R.  McNally 
M.  Stark 

626  Towne  Center  Dr. 

Joppa,  MD  21085 


Aberdeen  Proving  Ground 

6  Dir,  USAMSAA 
ATTN:  AMXSY, 

Mr.  M.  Miller 
Ms.  C.  Horley 
Ms.  D.  Smoot 
AMXSY-C,  M.  Carroll 
AMXSY-G,  M.  Sandmeyer 
AMXSY-J,  R.  Mezan 

8  Cdr,  CRDEC,  AMCCOM 
ATTN:  AMSTE-SI-F 
SMCCR-ST, 

Mr.  D.  Sloop 
Mr.  R.  Jablonski 
Mr.  J.  Razulis 
Mr.  J.  Walther 
Mr.  C.  Crawford 
Mr.  L.  Davis 
Mr.  L.  Baer 
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USER  EVALUATION  SHEET/CHANGE  OF  ADDRESS 


This  Laboratory  undertakes  a  continuing  effort  to  improve  the  quality  of  the  reports  it  publishes. 
Your  comments/answers  to  the  items/questions  below  will  aid  us  in  our  efforts. 

1.  BRL  Report  Number _ BM.-TB-31R7 _ Date  of  Report  ...pacaabat-lWO _ 

2.  Date  Report  Received _ 

3.  Does  this  report  satisfy  a  need?  (Comment  on  purpose,  related  project,  or  other  area  of  interest 

for  which  the  report  will  be  used.) _ 


4.  Specifically,  how  is  the  report  being  used?  (Information  source,  design  data,  procedure,  source 
of  ideas,  etc.) _ 


5.  Has  the  information  in  this  report  led  to  any  quantitative  savings  as  far  as  man-hours  or  dollars 
saved,  operating  costs  avoided,  or  efficiencies  achieved,  etc?  If  so,  please  elaborate. _ 


6.  Ge-'  jral  Comments.  What  do  you  think  should  be  changed  to  improve  future  reports?  (Indicate 
changes  to  organization,  technical  content,  format,  etc.)  _ _ _ 


Name 


CURRENT  Organization 

ADDRESS  _ 

Address 


City,  State,  Zip  Code 

7.  If  indicating  a  Change  of  Address  or  Address  Correction,  please  provide  the  New  or  Correct 
Address  in  Block  6  above  and  the  Old  or  Incorrect  address  below. 


Name 


OLD  Organization 

ADDRESS  _ 

Address 


City,  State,  Z.p  Code 


(Remove  this  sheet,  fold  as  indicated,  staple  or  tape  closed,  and  mail.) 
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